In this final chapter, we built the outline of a complete workflow starting with building and testing to continuous integration and automated deployment. We've covered some popular services or tools and provide other options for readers to discover and explore.
Among the varieties of choice, you might agree that the most appropriate workflow for your team is the workflow that fits the best. Taking people rather than technologies alone into consideration is an important part of software engineering, and it is also the key to keeping the team efficient (and happy, perhaps).
The sad thing about a team, or a crowd of people is that usually only a few of them can keep the passion burning. We’ve talked about finding the balance point, but that is what we still need to practice. And in most of the cases, expecting every one of your team to find the right point is just unreasonable. When it comes to team projects, we'd better have rules that can be validated automatically instead of conventions that are not testable.
After reading this book, I hope the reader gets the outlines of the build steps, workflow, and of course knowledge of common design patterns. But rather than the cold explanations of different terms and patterns, there are more important ideas I wanted to deliver:
- We as humans are dull, and should always keep our work divided as controllable pieces, instead of acting like a genius. And that's also why we need to design software to make our lives easier.
- And we are also unreliable, especially at a scale of some mass (like a team).
- As a learner, always try to understand the reason behind a conclusion or mechanism behind a phenomenon.