Continuous Integration to Reduce Release Time and Code Rework - Fusion PPT

Continuous Integration to Reduce Release Time and Code Rework


The closer a team works together on producing and deploying a software application, the better the chances of a timely, high quality result. DevOps is the way to achieve this, through tight collaboration between developers and operations staff, and automation of the different release steps. To move ahead in creating code, developers also need to work separately on individual parts of the code also code releases need to provide minor updates more often to provide the manageable continuous flow.

The Old Road to Integration Hell

A risk in working alone, however, is that difficulties will arise when all their efforts are integrated. In past or pre-DevOps projects, this integration phase was often pushed back until after all the development work had been done. This led to “integration hell,” where teams struggled to make different modules work together. Code then had to be rewritten or even scrapped, meaning a waste of time and money.

Getting Back on Track for Software Release

DevOps reduces this risk radically by using continuous integration (CI) / Continuous development (CD). Smaller, but more frequent code changes are committed to the version control system being used. A CI server then builds the overall application from the latest versions of the modules in the version control system and integrates with any number of automated testing tools to test the build. This could be any number of commercial or open source code testers like Sonarqube or YASCA to UI testers like Proof or Solenium. These integration test results indicate any problems or conflicts that can then be resolved, giving a solid, tested code base through the use of test harnesses, on which the next development can be based. With the higher frequency of integration testing, any rework or wastage is minimized.

Continuous Integration and Pipeline as Code

Continuous integration, which can be performed several times per day, has existed for some time. In DevOps, CI can be extended to a process of continuous delivery and deployment. Code that has passed CI testing is automatically made available, for instance, to a deployment management application for automated installation on a range of production servers. CI products include:

  • Jenkins. This continuous integration tool lets you automate your process to build your application, test it, and deliver it to the next release stages (for instance, quality assurance or QA), and to final deployment. Jenkins runs on a server. It offers its own build and test functionality, and can also work with popular build tools like Ant and Maven.
  • Bamboo. Offers triggers to start builds automatically when code changes are committed, with native support for Git, SVN, and Mercurial version control systems. Automated builds, tests, and releases can be combined into a single workflow to extend to continuous delivery and deployment.
  • Solano. You can use Solano as a SaaS solution or as a version for a private server. The tool allows code and tests to be written in a choice of programming languages. It works with Git and other version control systems, and produces reports on each build and test cycle with details on screenshots, logs, and metadata.
  • Atlas. Enabling DevOps over a number of popular cloud services, Atlas can run builds and integration tests with Packer, the machine image creation tool, from the same company (HashiCorp.) Atlas can also work with other build tools. Tested code can be entered directly into the Atlas workflow, or after the tested code has been definitively merged in a version control system such as GitHub.

These tools providing continuous integration possibilities also extend to handle much or even all of the overall DevOps workflow. They offer a “pipeline as code” approach, in which a workflow and deliveries from one stage to another can be automated, end to end.