Please enable JS

Continuous Integration (CI) and Continuous Delivery (CD) with Jenkins, GIT, Ant tool and Salesforce

18 Out. 2016 / Written by  / News

continuous integration 1

Continuous delivery is a series of practices designed to ensure that code can be rapidly and safely deployed to production by delivering every change to a production-like environment and ensuring business applications and services function as expected through rigorous automated testing. Since every change is delivered to a staging environment using complete automation, you can have confidence that the application can be deployed to production with the push of a button when the business is ready.

While continuous deployment may not be right for every company, continuous delivery is an absolute requirement of DevOps practices. Only when you continuously deliver your code can you have true confidence that your changes will be serving value to your customers within minutes of pushing the "go" button, and that you can actually push that button any time the business is ready for it.

continuous integration 1

Continuous delivery is a series of practices designed to ensure that code can be rapidly and safely deployed to production by delivering every change to a production-like environment and ensuring business applications and services function as expected through rigorous automated testing. Since every change is delivered to a staging environment using complete automation, you can have confidence that the application can be deployed to production with the push of a button when the business is ready.

While continuous deployment may not be right for every company, continuous delivery is an absolute requirement of DevOps practices. Only when you continuously deliver your code can you have true confidence that your changes will be serving value to your customers within minutes of pushing the "go" button, and that you can actually push that button any time the business is ready for it.

 

Continuous Integration (CI)

Continuous Integration, from now on referred as CI, refers to the development practice of frequently integrating and testing code into a shared repository numerous times a day, in opposite of the standard procedure of integrating only after the end of a development cycle or project.

In this way, CI allows a comprehensive and quick verification of errors and makes it easy to locate them earlier. Best practices of CI include:

  • Committing code frequently;
  • Using a dedicated integration build machine;
  • Categorizing developer tests;
  • Staging builds; and
  • Using continuous feedback mechanisms.

 

Continuous Delivery (CD)

Continuous Delivery, from now on mentioned as CD, can be defined as a part or extension of CI as it is a series of practices intended to ensure that every new code or change in code is delivered in production-like environments and tested automatically. This guarantees that the code can be safely and rapidly deployed to production and that business applications and services work as expected through a serious of rigorous automated tests.

As every change is delivered to staging environments, it is possible to be confident that every application can be deployed to production and be ready to work.

 

Tools Used

  • Salesforce.com
  • A source code repository GIT - this is the main source code repository where the code and configuration are. It uses 2 branches in GIT where Developers commit the code.
  • A continuous integration tool, in this case, Jenkins. Jenkins will regularly and automatically pull the code. If it detects any change (like the addition of a new code or changes in existing code), it will check out all changes, build and run the code against a sandbox environment, and produce the results on a web based dashboard.
    Jenkins does the migration of metadata between the GIT repository and the sandboxes with the GIT plugin and Salesforce Jar library for Ant tool.
  • SandboxSyncronizer 1.0 (Eclipse IDE plugin) - this tool was created to prevent more than one developer changing the same file at the same time in the same developer sandbox. The developer will use this tool to mark the files so that he is the only one that changes it. After he finishes the developing he will unmark the file so that others developers can in turn make changes in it. This way it is possible to coordinate the changes in code between developers using the same sandbox.
    Developer Process:
    1. Mark the file with sandboxsynchronizer;
    2. Make the code changes;
    3. Update the metadata in GIT (pull);
    4. Copy your changes to your git repository;
    5. Commit/push your changes;
    6. Unmark the file with sandboxsynchronizer.

Notes:

  • SandboxSynchronizer 1.0 – every user should use the same Force.com IDE version (Eclipse IDE plugin). This simplifies the developer's job while coordinating access to development resources. It integrates with Salesfroce.com IDE standard plugin but is not bounded (decoupled).
  • Every user uses the same Force.com IDE version (Eclipse IDE Plugin) to synchronize the code with the development sandboxes.
  • The build process is automated ensuring that the development environment is always updated.

 

Development and Automated Integration Cycle

Every developer commits/pulls their code into 2 branches in GIT. The two branches are:

  • Master - for new releases; and
  • Business as usual (BAU) - for fast track and support (bug fixing).

Once the code is in a GIT branch there is an automated process triggered by events (GIT commit/update) by Jenkins (using the Ant migration tool) to deploy the code in a developer sandbox (qaXXX).

The same automated process happens from the QA developer sandboxes to a Production support full sandbox – PreProd – that has all the data from the Production org.

The final process is the same automated deploy in the real and final environment of Production, but is only executed when the continuous integration team decides (ie. in a release or for bug fixing).

This combination of Jenkins and the Ant tool does all the pushes from the GIT branches all the way from the development sandboxes into production.

 

 

Rebasing the code

The deliver process between BAU and master is the same, but the branches are different. The integration of changes from one branch to another; the rebasing and the merge are done by the developer. After a change is made in BAU, it must be merged to the master branch to be in the next release.

 

Conclusions

This process allows to maintain a version control system, automate the build and make the build self-testing. It also allows to test in a clone of the production environment, following the principles of CI.

The automation of steps in the CI and CD processes make CI and CD easier and faster and highlights even more the benefits and vantages of CI and CD.

Automation is the key word here.

  

References:

   

Authors


Manuel Conde
Lead Technical Architect
Este endereço de email está protegido contra piratas. Necessita ativar o JavaScript para o visualizar.

 



Rate this item
(0 votes)
Last modified on segunda, 19 março 2018 14:33

Sobre Nós

A Right IT Services garante soluções de IT, arquitetura de serviços, design e desenvolvimento de software e respetivos testes.

Contactos

Rua Odette Saint Maurice

Lote 3B, Edifício L, Piso -1, Escritório A
1700-097 Lisboa | Portugal

+351 218 232 261

+351 911 981 920

contact@rightitservices.com

Segue-nos no Instagram

Este site usa cookies para melhorar a sua experiência.

Se não alterar as configurações do seu browser, aceita as condições. Saiba mais

Entendido