Learn about what else you need to know to make all of this work for you.
- Alright, now you've seen a sample pipeline and we've talked about best practices. Keep everything in version control, use artifacts, minimize branching, commit frequently, shift testing left, and so on. - But there's some best practices for your overall pipeline you should keep in mind. - [Man On Right] The key is that each developer has to understand that the successful build and deployment of their check-ins is their responsibility. Not a build engineer, not a QA engineer, not an OPS engineer, theirs.
- Yeah, even if other people are involved in that chain, your change is not done until it's successfully deployed in production. - [Man On Right] Small changes and build quality in. This is the lean mantra that should always guide your decisions around your pipeline. - That's right. You know, the more changes you make at once and the longer you delay testing, the more bugs you have and the harder it is to find them and fix them. - That's right. Let's talk broken builds. - [Man On Left] While broken builds aren't bad, per se. You don't want them to linger because it blocks the team and it temps people to pile on more changes that don't get tested.
- [Man On Right] Other engineers shouldn't check-in or merge to master when the build's broken. If they're in a hurry, they should help fix the problem. You should always watch to make sure your build succeeds and never leave a broken build behind. - [Man On Left] When your commit breaks the build, the build pipeline should stop and you should immediately fix the problem, usually by reverting to a prior version and working on the fix at your leisure. Attempts to push forward and fix the build in place shouldn't be allowed to really take too much time. - [Man On Right] Of course good testing discipline facilitates success.
High quality testing, automated testing, is crucial to continuous delivery. - [Man On Left] Developers should always run the test locally before check-in or have a branch that builds and runs them before merging into master. - [Man On Right] Don't allow flaky tests and don't just comment them out or ignore them. This degrades confidence in your pipeline. Tests are code, log a bug, and fix them stat. Don't say you don't have time. What you don't have time for is delivering big bags of buggy code, like you used to.
- Keeping the build clean and test passing, that's your first priority and you'll be able to rely on your build in that case. - I'm not going to say that you should have no manual QA. But that QA should be focused on very high value activity and finding things that are impossible to find with automation. Not doing work a computer should be doing. - Yeah, use QA as expert consultants on how to construct good tests, to build maintainable UI tests, valid performance tests, and doing resilience testing. - [Man On Right] The same basic concepts apply to the deployment stage.
Automate your deployments and use that automation at every phase. From on the Dev desktop, to CI deploys, to production deploys. - Every piece of your environment is code that should be continuously built and validated. When your environment creation is automated, then each one is nearly identical and one of the largest sources of surprise bugs is eliminated. - [Man On Right] Now some advanced topics. Keep the build and deploy fast. When anything starts taking more than a couple minutes, you should start looking into why.
Make component builds and test runs parallel, tune time outs, and build system parameters. - [Man On Left] Remember the 70% unit testing, 20% integration testing, and 10% end to end testing rule from our testing philosophy video. The slower the build, test, and deploy is, not only does it effect your cycle time, but it becomes hard for the developers to pay proper attention to the build. - Dan Bodard did a great presentation, back in 2012, called Crazy Fast Build Times or when 10 seconds starts to make you nervous, where he presents a lot of ideas to really dig deep into removing time waste from a build cycle.
The more you stick to these practices, the better your continuous delivery will work. I work on one system that's pure continuous delivery. Every piece of infrastructure build, all the tests, all the app code, even the monitoring configuration. It's all in source control, it has a build, it becomes an artifact, it's deployed across our environments, and it's tested at multiple points. Developers can check-in code and minutes later it's in production. It's become routine. All it takes is the discipline to say, we don't do things manually or without tests.
- Alright, that all sounds great. In our next video, we'll talk about the challenges you're going to face doing continuous delivery in the real world.
- Benefits of continuous delivery
- Building your own pipeline
- Version control practices
- Building artifacts
- Testing and continuous delivery
- Application deployment and release
- UI testing in action with Robot
- Security testing in action with gauntlt
- CI/CD best practices