7 Things You Must Know About Continuous Integration

CI is an automation technique. Automation techniques reduce manual processes and enforce consistency which then results in better quality. Continuous Integration (CI) is an agile development practice where developers integrate codes into a shared repository several times in a day. An automated build then verifies each of these check-ins. Instead of building features in isolation and integrating them at the end of the development cycle CI code is integrated by the developer as it is built. This procedure helps in detecting problems that come up in an application pretty quickly. Integration errors are detected at the earliest.

Right from code commits to a version control system that kicks off compilation, testing and packaging of the code the CI process is involved at all the stages of product development lifecycle.

Let’s look at the important aspects of CI.

 

  1. Problems Are Detected Early

When you add a CI server to your build , you are always aware of the health of your software. When you build and integrate your software just before testing you have bigger risk of a software failure. When you constantly add new features to the code and fix bugs the codebase is in a state of flux. It is not stabilized. If you are not able to figure out the reason for destabilization you would not be able to fix it. CI flags problems early and they are therefore fixed early. Developers are able to discover conflicts at the boundaries of new and existing codes early when the conflicts are at the easily resolvable stage.

 

  1. CI Fixes Responsibility Of Bad Codes

Frequent , small development changes are made to the application. These frequent updates ensure each developer understands his role. He has to integrate the code/make changes to the code and ensure that the application continues to run effectively after he has integrated his part of the code. Each developer does the same. Problems are fixed before the second developer integrates his code to the application. No stepping on each other’s toes. Everyone is clearly responsible for their part of the code.

The goal of the development team is to ensure the build doesn’t break at any point. A developer who breaks it immediately gets it back on track.

 

  1. CI Increases Developer Confidence

When an organization follows Continuous Integration practices effectively its results can boost developer confidence in producing quality software. They don’t have to do repetitive tasks which can be automated.

With each project, with each build the team knows that the tests are being run, coding standards are being adhered to and the resulting product will be something client and the team will be proud of. With Continuous Integration you get feedback immediately so the developers are able to judge the behaviour of the build adequately and are able to balance the system quickly. CI practices are built around a centralized server which continuously pulls in all source code changes as developers commit them. Whenever a failure is spotted the development team fixes the build before adding any more code changes to it. At all time the team is on top of system’s working state and slowly gets into the practice of delivering good quality code for the build so that it passes the muster.

 

  1. CI Process Can Be Designed For Specific Build Attributes

If there are any specific quality attributes that your customer wants to see in the build the CI process can be designed to reinforce that. If security of the system is of prime concern for the stake holders the build server should be configured to run against a comprehensive suite of security tests. If vulnerabilities are found the tests should fail the build. If performance of the build is the chief requirement the build server should be put through automated performance tests to measure the speed at which the key operations are executed. The build should fail if it is slow and takes too much time in executing the operations. CI process thus can ensure that the desired specific attributes are there in the build. It ensures the quality of the build.

 

  1. CI Relies On Robust Test Suites

Continuous integration process completely depends on robust test suites and the automated system which runs those tests. Everytime a developer integrates his code, automated processes make the build with the new code. Carefully created test suites with required attributes are then run against the build. This way integration problems if any, come to the fore. If any problem is found the build or the test phase fails the developers get an alert to fix the build. It is very important therefore to create quality test suites with different test cases –each with a different test script which demonstrates  that the build adheres to a specified set of behaviour. The suites ultimately improve the quality of the build.

CI is thus accomplished by automated test technique within a unit test framework. A build server could therefore be designed for performing these tests so that the development team continues to merge requests while the tests go on. The automated test suite should be comprehensive and stable so that developers have the confidence to deploy every passed CI build to a staging and then later to production environment.

 

  1. Continuous Integration, Continuous Delivery and Continuous Deployment

The concept of Continuous Delivery is an extension of the concept of Continuous Integration. In continuous delivery the software delivery process is automated. The automated delivery ensures that the teams are able to deploy their codes to production at any time. The code is continuously delivered to a user base which could be QA or a set of customers for review and inspection. Codebase is always in a deployable state and therefore the release of software becomes a routine event which needs no complex coordination or late stage testing. Continuous delivery can feed business logic tests because unit tests sometimes do not catch all the business logic issues particularly the design issues.

Continuous deployment is an extension of continuous delivery process. There is no batching in the staging area and no long UAT (User Acceptance Tests) processes. In continuous deployment each build that passes the full test cycle gets automatically deployed. While the new code is automatically deployed to all users, developers have specific techniques by which they can activate the new features of the latest deployment at a later time. They can also use their discretion to release the feature to a select subset of users.

Continuous deployment relies on extensive instrumentation which ensures that new functionalities made available to users do not result in any undesirable incident. It needs an infrastructure that supports the rollback of newly deployed features with bugs that are not found in automated tests but are found when users use the product.

 

  1. In CI, Best To Keep The Build Server Independent

Independent build servers simplify developer’s workflow and reduce chances of mistakes. It checks out latest code with the help of necessary software, can replicate the target environment (with right OS and other settings) so that everything that works on developer’s desktop works in production too. Build server catches the test errors developers miss. Centralized builds provide easy access to code metrics- details on which tests passed, which failed, the frequency, if the codes are well covered by tests and more is provided. Easy and automated product deployment so that developers don’t have to do it all manually. It enables good tuning between developers and QA. QA team knows from where to get latest, proper build. Builds for release branches can be set for extra safety. No chance of stray DLLs on developer’s machine interfering with the final product giving out random results.

The build server builds on a machine which is untainted by developer dependencies after retrieving everything from source control. It is a neutral zone for all developers. It decreases “But-it-runs-on-my-machine” kind of scenarios.

With Independent build server present in a corner, it is always better for everyone to have a known consistent environment where software is built to avoid dependencies on different local dev boxes. If a developer breaks a build, other developers are not affected. Developers don’t trip each other. It motivates developers to write better codes. You can get more and quality codes from developers. It is easy to attach a build status dashboard which can be used by management who are then able to get a better handle on the status of the project.

 

Wrapping Up

Continuous Integration is one such development practice which ensures there is less conflict during development, project gets delivered on schedule and all the stakeholders are satisfied. It is a part of agile development which dramatically increases the chances of developing a quality product. Your build process is defined by a script and is under source control. A CI server like Jenkins, Hudson, QuickBuild, CruiseControl etc. helps it perform all its functions. We at OpenXcell work with agile technologies to optimally utilize our resources and ensure our clients get a quality product on time. That is all from my desk for now. Until next time, Adios.

Priyanka Garg

Priyanka Garg

A writer, a wordsmith. Curious about the internet of everything. Interested in the cutting edge landscape of mobile apps and SAAS products. Blogs for OpenXcell - A Mobile App Development Company. Loves Jazz and Blues.