Continuous integration is in my opinion the most important practice to successfully deliver good software. Continuous integration should go beyond a simple set of practices and tools to build your source code every now and then; doing so is continuous compilation, not continuous integration.
Continuous integration should drive the way the software gets build and how the different actors from the project interact with each other.
The five main characteristics of continuous integration
In my opinion these following five characteristics are the main characteristics of an effective continuous integration.
1.- QA and development work together.
Having QA and development working together mainly means two things:
- There are no handovers between development and testing. Coding and testing are not two separate processes, they are performed in parallel, and one can’t be completed without the other one and vice versa.
- Developers and Testers have a common goal, they don’t perform different activities, developers are not just focused on developing and testers in testing. They share a common goal, produce quality software in coordination with the product owner expectations.
2.- QA act as a business representative for the developers.
The integration with the business requirements is critical to successfully develop quality software, failing to do so can have catastrophic consequences. QA should take special care special of the integration with the business requirements, they should make sure at every time that all the tests and developments are aligned with the business requirements.
3.- The build is the most important asset in a software development.
The build is the image of all the previous activities; it contains the software which is already been developed.
- The build should never be broken
- If the build breaks, fixing the build is everyone’s top priority
4.- Continuous feedback and inspection.
Knowing at every time what is the status of the project is also critical, there are a few things to be considered:
- Automatically check the build every time someone checks code in.
- Run full regression tests every few hours.
- Every time a build runs, automatically generate reports including, code coverage, code quality metrics, new lines of code…
5.- Communication is king
Everything is about communication, developers talking to testers and business, and testers doing the same. An important rule of thumb for communication is called “power of three”, in every single important discussion there should be at least, a developer, a tester and a representative from the business, if all the rest works, but communication doesn’t, the project is doomed to fail.
Top recommended actions to improve your continuous integration.
1. For every story, first, do a high level design of what needs to be tested. Prepare this design with QA, development and the product owner. Drive your development with that test design.
2. Only consider two states for your stories: “in process” or “completed”. Don’t use intermediary states as “in QA” or “60% completed”. If you do so you will never have QA and development working together, but against each other.
3. Have testers pairing with developers every now and them. This will enhance the communication between them, and will help to understand what needs to be tested.
4. Make QA people work very close with the product owner. Make sure they keep him well informed of what is going on in the sprint and show him if possible any progress in the stories.
5. Make developers responsible for breaking the build. Developers should perform two steps before committing any code:
- Update all source code.
- Build locally the whole application. (If the complete build takes too much time, split it and make the developers run all the unit tests before committing any code).
6. Make your CI continuous integration server to run the build every time someone checks in any code into your CSM. This will make sure that no one checks in broken code.
7. Run full regression tests as many times as possible during the day. All your tests should be automated, hook them if with the build which gets trigger when anyone commits code, if they take too much time, schedule them to run as many times during the day as possible.
8. Add a few visual devices in the office to tell when the build is broken. There are many visual devices that can be configured with almost any continuous integration server, place them in the office strategically, so whenever they turn on, everyone will realize that the build is broken, some examples of this devices are: traffic lights, a red light, a lava lamp…
9. Include an inspection report for every build. In modern continuous integration servers is easy to add different plug-ins so for each build you can obtain additional information, as test code coverage, compliance with coding standards, lines of code duplicated…