Continuous Integration Best Practices
Continuous Integration Concept is excellent and can help software application to achieve high quality and stability. However, the concept and tools is useless unless used properly. To help, here are Continuous Integration Best Practices:
- Maintain a single source repository
- Automate the build
- Make your build self-testing
- Every commit should build on an integration machine
- Keep the build fast
- Test in a clone of the production environment
- Make it easy for anyone to get the latest executable
- Everyone can see what’s happening
- Automate deployment
How to do it
- Developers check out code into their private workspaces.
- When done, the commit changes to the repository.
- The CI server monitors the repository and checks out changes when they occur.
- The CI server builds the system and runs unit and integration tests.
- The CI server releases deployable artefacts for testing.
- The CI server assigns a build label to the version of the code it just built.
- The CI server informs the team of the successful build.
- If the build or tests fail, the CI server alerts the team.
- The team fix the issue at the earliest opportunity.
- Continue to continually integrate and test throughout the project.
- Check in frequently
- Don’t check in broken code
- Don’t check in untested code
- Don’t check in when the build is broken
- Don’t go home after checking in until the system builds
Rackspace have compiled 10 Key Principles of Continuous Integration, of which 6 of them contains best practices principles:
Revision Control has been the basic standard for software development teams for the last couple of decades. The purpose of revision control (also known as version control or source control) is to manage changes made to the files that make up the code for your software project, no matter whether it is a product, website or any application. Revision control allows you switch back and forth between different versions of code using a single command, provided the changes were committed. This replaces the “messy process” sans revision control: countless folders with various versions of code files from different dates. However, when you employ this outdated approach to code management, you lose the ability to have multiple people work on an item and then later merge the work together.
In short, Revision Control not only makes your code base manageable when dealing with making/moving between changes, it also makes it much easier for your developers to integrate their code. This is the root of Continuous Integration; it is the best investment (though most version control systems are free) that you can make on behalf of your developers for your business.
Revision Control allows you to easily do things like Build Automation as well.
Build Automation refers to the ability to either automatically trigger and/or build a clean version of your product, application or website via a single command or action from raw components. Many teams now take this further and allow their systems to be built solely from the code that is obtained from their version control. Build Automation can reduce a 30-minute task to several seconds. Establishing the patterns that your developers perform to start a clean or new system (whether this be a production, staging or development build) will save you time in the long term.
Build Automation does come with risk. There are times when the process for building must change – affecting the way your application is built. Identifying your product’s building process can be a time investment that will front load the development costs. But in the end, the efficiency and ability to get new employees up and going quickly with an environment is well worth it, particularly in bigger teams and shops.
Build Automation allows you to automate the deployment of your product application as well.
Automated Deployment is the process of consistently pushing a product to various environments on a “trigger.” It enables you to quickly learn what to expect every time you deploy an environment with much faster results. This combined with Build Automation can save development teams a significant amount of hours.
Automated Deployment saves clients from being extensively offline during development and allows developers to build while “touching” fewer of a clients’ systems. With an automated system, human error is prevented. In the event of human error, developers are able to catch it before live deployment – saving time and headache.
You can even automate the contingency plan and make the site rollback to a working or previous state as if nothing ever happened. Clearly, this automated feature is super valuable in allowing applications and sites to continue during fixes. Additionally, contingency plans can be version-controlled, improved and even self-tested.
Testing can happen in many different ways using methods you have probably heard thrown around as buzzwords. Some of these involve automated testing like unit testing and interface testing. Self-Testing Builds are the next step. Once you have tests that can be automated, executing them simultaneously with a build is usually not too much more work. Your team will have more awareness on what is going on with your product. Obviously, the more you test (and the more good tests you have) the greater visibility you have into the state of your product before release. This could possibly be the difference between being a reactive or proactive company. Remember: testing is only as good as the environment in which you test it.
Testing in a Clone of Production
Making it a point to minimize the variables in which you are testing is just good planning. Every developer has that story of burning the proverbial midnight oil because their perfect build didn’t work on the production environment like it did on the staging or development environments. Making sure your testing environment is as close to production as possible allows you to minimize this risk.
There are several options for configuration management when it comes to building server machines that allow you to manipulate the configuration of several machines with a single versioned file. This allows developers to see exactly what changes were made and when and by whom they were made – this increases accountability and efficiency. Note: for best results, make sure your developers frequently commit their changes.
Committing is the act of creating a new version in a revision control system. Committing marks a point in the history of the code base where you are able to switch over to that point and use the changes made. Frequently, this isn’t just when a new release of the product is made. In fact, each release of your product may be made of thousands of commits – thousands of points in time where you could go back to the state of the code base as it was in that moment. This is a good thing; the more modular the commits, the easier it is for developers to merge, move, add and remove changes with other developers’ work. It also gives them a point of comfort, because if something does go wrong, they can start back where they were the last time they committed work. Making this a frequent occurrence ensures that at the end of the day, everyone’s code can be updated with the latest changes – making code consolidation easy.
Those are Continuous Integration Best Practices as well as steps to make Continuous Integration works. Now, it is your turn to apply it in your projects.