A sneak peak into Continuous Integration

What does the development of a software product involves? Is there more than programmers coding at their PCs and managers telling them what they want? What is the real meaning of ‘release’?

In the old age of software development, a development team would have to deal with incredible amounts of organization in order to establish a reliable development process. Tasks such as testing manually and doing semi-scripted deploys would be demanding chores. The development process in general would be described as a dread or wake to some degree rage.

This is the reason why software development is moving towards continuity. The recent emphasis on continuous integration, built-in testing, constant monitoring, and analytics feedback all point toward an overall trend in the software industry: increasing the ability to fine control but at the same time to make everything faster.

Continuous Integration is the practice of testing each change done to your codebase automatically and as early as possible. Continuous Deployment follows the testing that happens during Continuous Integration and pushes changes to a staging or production system. This makes sure a version of your code is accessible at all times.

The main goal of continuous integration is to reduce integration problems and allows a team to develop cohesive software more rapidly. Sound like a pretty good deal, doesn’t it?

To accomplish this you don’t need a expensive and complex tool. The essence of it lies in the simple practice of everyone on the team integrating frequently, usually daily, against a controlled source code repository. Some things to keep in mind include:

• Although Continuous Integration is a practice that requires no particular tooling to deploy, we’ve found that it is useful to use a Continuous Integration server.
• The term ‘Continuous Integration’ originated with the Extreme Programming development process, as one of its original twelve practices.
• Everybody develops off that shared stable base and never gets so far away from that base that it takes very long to integrate back with it. Less time is spent trying to find bugs because they show up quickly.

So, let’s take a looks at the main principles of continuous integration according to our good friend Mr. Fowler:

1. Maintain a Single Source Repository with everything inside including test scripts, properties files, database schema, install scripts, and third party libraries
2. Automate the Build, you should be able to bring in a virgin machine, check the sources out of the repository, issue a single command, and have a running system on their machine. This gives you the confidence to experiment, implement new features, and ship updates quickly.
3. Make Your Build Self-Testing by including automated tests in the build process.
4. Everyone Commits To the Mainline Every Day. As with any commit cycle the developer first updates their working copy to match the mainline, resolves any conflicts with the mainline, then builds on their local machine. If the build passes, then they are free to commit to the mainline.
5. Every Commit Should Build the Mainline on an Integration Machine, you should ensure that regular builds happen on an integration machine and only if this integration build succeeds should the commit be considered to be done.
6. Fix Broken Builds Immediately. It does mean a conscious prioritization of a build fix as an urgent, high priority task.
7. Keep the Build Fast. For most projects, however, the XP guideline of a ten minute build is perfectly within reason. Most of our modern projects achieve this.
8. Test in a Clone of the Production Environment. A significant part of this is the environment within which the production system will run. If you test in a different environment, every difference results in a risk that what happens under test won’t happen in production.
9. Make it Easy for Anyone to Get the Latest Executable
10. Everyone can see what’s happening. Continuous Integration is all about communication, so you want to ensure that everyone can easily see the state of the system and the changes that have been made to it.
11. Automate Deployment. To do Continuous Integration you need multiple environments, one to run commit tests, one or more to run secondary tests. Since you are moving executables between these environments multiple times a day, you’ll want to do this automatically.

We already talked about the main benefit of taking continuous integration on board, while developing software. However, there are other benefits that include:

• Faster reaction times: the most obvious benefit of CD is that it allows quick reactions to stimuli, both external and internal.
• Reduced risk: under a continuous delivery model, software is “released” constantly (though not necessarily to customers). Therefore, the ceremony and the risk around releasing is reduced.
• Exposed inefficiencies and costs: when constructing a pipeline, it will become clear where humans are involved, what bottlenecks exist, and what low-hanging automation fruit there is to pick.
• Flexible release options: moving to a continuous delivery model requires the build-out of infrastructure, both in an operational context and a software architecture context. But once that’s done, it provides the business with more flexibility in how it delivers features and fixes.

Generally speaking, that teams are as soon as ready to deploy, when they can. So even if it’s midnight, if your feature is ready to go, you can check-in, deploy, and start talking to customers about it right away. No extra approvals, meetings, or coordination required. Just you, your code, and your customers. It’s pretty satisfying.