Continuous Integration: Business Advantages

Software development work impacts business: the code quality, the time spent and the visual work shown, all affects business for our company and our clients. Continuous Integration (CI) helps developers help business by providing processes that fulfill those necessities. To understand how CI provides quality code, efficiency, and shows prowess as a development team, you must understand what CI is and how developers use these practices to make day-to-day software development for your business run smoothly.

What is Continuous Integration?

Continuous Integration is certainly a “buzzword du jour” in software development today, but there are many misconceptions surrounding the topic. You’ve probably run into this terminology in blogs, articles, and internal meetings and heard about:

• Automated Testing
• Test Driven Development
• Automation

While these can be parts of your CI process and benefit your business, they don’t account for the whole CI picture.

Continuous Integration is the process of literally Continuously Integrating the code that your developers create frequently—at least daily and often multiple times per day. The purpose is to find problems quickly, solve them, and deliver more rapidly. CI is a best practice for software development and is guided by a set of key principles.

The 10 Key Principles of Continuous Integration: Ranked in Order of Priority

Each of the ten principles complements each other, but there are some that take precedence when you are facing different project factors, including size and budget. Here they are, explained and ranked in priority. The principles are ordered from most to least beneficial for a typical project. We will be addressing more specific project considerations for using CI in an upcoming post.

Revision Control

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 to switch back and forth from 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 easy 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 could make on behalf of your developers for your business.

Revision Control allows you to do things such as Build Automation easily as well.

Build Automation

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 take a 30-minute task and turn it into several seconds. Establishing the patterns that your developers perform to start a clean or new system (whether this is 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 which 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

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” less of 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 allowing applications and sites to continue during fixes. Additionally, contingency plans can be version-controlled, improved and even self-tested. 

Self-Testing Builds

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 of 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 a 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 in is just good planning. Every developer has that story of burning the proverbial midnight oil because their perfect build didn't work in the production environment as 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, when, and by whom—increasing accountability and efficiency. Note:  For best results, make sure your developers frequently commit their changes. 

Frequent Commits

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 one is 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.

Code Consolidation

Code Consolidation is typically best at the end of the day; this is the point where all development features are compiled and merged. Not everyone follows this methodology; some prefer to merge only full complete features, however, Code Consolidation can be quite useful.

First, developers spend less time trying to merge their changes with one another. Although this process is usually automatic, there is a case in which one developer's changes may conflict with another developer's changes. This happens when both developers end up changing the exact same line of code. Catching these early while it's still fresh on their minds will increase efficiency.

Secondly, if you established the Automated Building on a test server and those builds are Self-testing Builds, you will be able to track the performance of your product throughout production. Keep in mind, as code changes, tests need to change as well.

Lastly, it gives your other developers visibility on code that another developer is writing. This enacts a system of checks and balances, particularly if you have set up a code review process for every merge that is made into the main development branch. You can correct problems earlier and improve the quality of your code, ultimately leading to a better product.

Fast Builds

Time is money. Fast Builds give you that time. You don't want to pay your developers for watching YouTube every time they have to build a new environment. Additionally, depending on the trigger that is set up for an automated build made for testing, a build can take so long that the trigger fires more than once before an actual environment is completely built. This is bad if it happens on a daily basis. There are times where this will happen anyway if your trigger is something like "on every merge to the development branch", and it's close to a major deadline. Fast Builds allow developers to get on their feet faster, receive test results faster and see your product faster.

Build Availability

It is important to have a current development and staging build available at all times. Regardless of your Automated Testing, there are some things a computer cannot detect or it makes very little sense to try and make it do so. In these cases, manual testing is required.

Additionally, you can provide a public (or pseudo-public) version of your build to your clients.  Everyone loves a sneak peak into the new great features that are coming along—availability is key.

Test Result Availability

Who determines what tests passed and what tests failed? Test Result Availability gives visibility on the results to developers, managers and client stakeholders. This principle supports the continued system of checks and balances. There are many test management products that show the test results in a comprehensive graph of passes and fails. Typically, these products let you drill down into the results for in depth analysis. A reconciliation of each test error each day can be performed so that everyone knows exactly why it failed and when it will be fixed.

Like the Build Availability, allowing your clients to see test results can be assuring. It is important to note that you should only show them the results on the builds that you show them. For instance, if you have a staging environment that is only built at every stable development cycle, then show them tests related to that build. This gives your clients confidence in your ability and your devotion to quality.

Final Thoughts

When you are getting your business started with Continuous Integration, remember you are doing three important things:

1. Improving the quality of your code. You can achieve a better quality product application or website project.
2. Making your developers more efficient. You can receive “more bang for your buck” and narrow down the cost of software projects.
3. Showing your prowess in your market. You let everyone know that you have the best practices that make the highest quality work.

Also, remember that CI is not about a set of tools or a single process. It is a development practice that requires following the key principles and taking team responsibility to ensure the quality of the application or website that you are building. 

In our upcoming posts, you can learn about some of the tools of the trade for CI implementation and specific business considerations for use of CI in web development projects.

Read Part II here.