The goal of Continuous Integration (CI) is to provide developers rapid feedback on their work: if a defect is introduced into the code base, or new code is causing regressions in other parts of the code, it can be identified and corrected as soon as possible.
Especially on projects with several developers, with individual modules or functionalities developed in parallel rather than one at a time, automated integration of the individual features is a must-have.
CI has changed quite a bit over the years. Originally, a daily build was the standard. Nowadays developers commit their work to a shared repository multiple times a day. Once the changes have been committed, specialized CI software such as Jenkins or Travis-CI runs automated builds and tests to check to code for defects. By integrating changes on a regular basis, defects are typically smaller, less complex and easier to resolve.
At TenTwentyFour1024, we use Jenkins to run integration tests on all our locally hosted projects as soon as a commit has been approved in code review. Each Jenkins job is specifically tailored to the projects, with multiple jobs covering individual layers of the Testing Pyramid. Integration tests usually run second in our testing pipeline, since they take longer than unit-tests and collection of software metrics, but they result in detailed reports for any failing test.
Continuous integration and continuous deployment are two very important elements of building any successful application. Since development work-flows have changed from releasing and manually deploying once in a semester or even less often, to a model where releases and deployments may happen several times a day, deployment must be easy, fast and safe.
TenTwentyFour1024 has been relying on Capistrano to automate the deployment process of their software.
Written in Ruby, Capistrano is a remote server automation tool used to reliably deploy, update and maintain web applications. Tasks like updating the application’s source from a repository, restarting a web-server, renaming files or running database migrations can be performed by scripting arbitrary work-flows that will execute over SSH connections, keeping application downtime to less than a second in most cases. Built-in fail-safe mechanisms allow for no hassle application and database roll-backs should something ever go wrong.
For projects where this is possible and where the client does not wish to first acknowledge any changes on a staging environment first, our Jenkins server directly deploy updates to an application from the last job in a pipelines. Any new features thus added by a developer, sufficiently covered with unit and functional tests and not introducing any new bugs or regressions is thus automatically available in your application in a matter of a few minutes.
With the correct tools and the necessary experience and know-how, changes to your applications can be available to you faster than you know. If you’ve seen changed files copied to the production environment on your server by hand and database changes applied on the live production system, or if you have experienced applications being down for a dozen or more minutes during an upgrade, let us help you improve the deployment work-flow and decrease the time your spend waiting…