Continuous Integration / Continuous Development
May 1, 2017
Continuous Integration and Continuous Development is the ideal step for agile teams. The goal here is that every time a developer makes a change, that change is quickly tested with automated testing. This testing ideally would include unit and integration testing. In a perfect world this testing would be performed as a step in the code check-in, required all tests to pass before the code is allowed to be checked into the development branch, or merged to the “master” branch. However the world is seldom perfect. In many cases development teams do not have the resources needed whether developers to set this environment up, or the systems to maintain such an environment. Hopefully even with limited resources, you are working on a plan to reach this level of continuous integration, baby steps in this direction can go a long way toward increasing your productivity and the quality of your code.
As a developer this is of great concern to me. In order to have a CI/CD in a virtual office, we have to consider.
- Source Control System – GitHub meets our criteria here very nicely. It provides the source control management and integrates with most build servers.
- Build Server – Jenkins, CircleCI, or another alternative generally integrates nice with GitHub. Allowing for builds to be triggered when code is delivered to a branch. Most build servers integrate some testing into them. JUnit is a common until testing framework that build servers integrate. This is your first line of automated testing. Let your build server run the JUnit tests on the recently built server. Notifying the developer who made the change if the testing fails.
- Test Server – This could be Travis CI, JMeter, additional JUnit tests, or another test platform. This provides a more robust set of testing. Allowing for UI testing, mocking and additional tests. Sometimes this can be integrated with your Build Server as well.
- Deployment Server – IBM Urban Code Deploy, Travis CI, automated scripting, Puppet, Chef or other deployment application that can automatically deploy a build out to a test environment.
- Test Environment – This is an environment that mimics a production environment. Your deployment server would install the new build in this environment. Additional automated testing can be performed here. Along with manual testing that you may wish to perform. Testing such as:
- Performance Testing
- Scaling Testing
- Fail-over Testing
- Middleware Testing
- Production Environment – Finally if your testing all passes, you can have your deployment server deploy the build to this environment your Production Environment. Typically this fits the profile for cloud software over on-premise software.
While the primary scenario is great, for your system integration point or master branch, you certainly do not want a random developer to trigger an build of their branch they are working on to be pushed to your production environment. There are several levels that you need to be able to handle.
- Full Integration Build – Depending upon the complexity of your build, it may or may not be feasible for your developer to build everything locally. When that is the case it maybe necessary for the developer to trigger a Full Integration Build to verify that everything builds correctly with their changes. This is not an integration test, this is to verify the build process is fully functional with the changes on their branch.
- Test Build – This would be a complete system build, that also performed the automated testing. This allows the developer to reach a better level of confidence their changes do not break other modules and that integration is fully functional.
- Test Environment – This would be the full build, test, and deployment of the code into a test environment. Depending upon your level of Continuous Integration / Development each developer may have their own environment, each team, or maybe environments that can be reserved.
Depending upon how your testing is structured, you may have additional testing performed by a Quality Assurance team. This ideally should not include automated testing, as ALL automated testing should be integrated into the build as part of the Continuous Integration steps. This should be any non-automated testing that is required.
So often overlooked is the ability for your support organization to be able to trigger a build on a specific version and have it tested and deployed to a test environment. The main difference here between the Development Branch Test Environment is this is a specific released version a customer would have, instead of a development branch. It should be possible to build any of the old releases and have them built consistently.