This is a guest post written and contributed by Allan Chappell, a developer with Promet Source, a Rackspace partner and an interactive web development agency specializing in open source tools.
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 and 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 or Automation. While these can be parts of your CI process and can 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 10 principles complements one another, 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.
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.
Code Consolidation is typically best at the end of the day; this is the point when 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 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.
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.
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 peek 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 everyone knows exactly why it failed and when it will be fixed.
Like Build Availability, allowing your clients to see test results can be assuring. It is important to note that you should only show them 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.
When you are getting your business started with Continuous Integration, remember you are doing three important things:
- Improving the quality of your code. You can achieve a better quality product application or website project.
- Making your developers more efficient. You can receive “more bang for your buck” and narrow down the cost of software projects.
- Showing your prowess in your market. You let everyone know that you have the best practices that produce 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.