Vital Bucket

A Bucket Containing Your Desired Vital Knowledge...

How to implement CI/CD in salesforce development.

CI/CD Implementation

Technology is getting upgraded day by day and to survive in this fast growing world, the process of delivering solutions to customer is very competitive and should be fast .
Continuous Integration and Continuous Delivery is one of the way in development world to help you achieve above requirement. Here you can learn how to implement CI/CD in your project for the fast delivery.

What is CI/CD?

Continuous integration (CI) :

It s a development practice where developers integrate code into a shared repository frequently, preferably several times a day. Each integration can then be verified by an automated build and automated tests. While automated testing is not strictly part of CI it is typically implied.
ci.png

Continuous delivery (CD) :

It Continuous Delivery is the ability to get changes of all types—including new features, configuration changes, bug fixes and experiments—into production, or into the hands of users, safely and quickly in a sustainable way.

 

Benefits of CI/CD:

  • Early Bug Detection: If there is an error in the local version of the code that has not been checked previously, a build failure occurs at an early stage. Before proceeding further, the developer will be required to fix the error. This also benefits the QA team since they will mostly work on builds that are stable and error-free.
  • Reduces Bug Count: In any application development lifecycle, bugs are likely to occur. However, with Continuous Integration and Continuous Delivery being used, the number of bugs is reduced a lot. Although it depends on the effectiveness of the automated testing scripts. Overall, the risk is reduced a lot since bugs are now easier to detect and fix early.
  • Automating the Process: Continuous integration server can monitor the main repository and run the tests automatically for every new commits pushed.
  • The Process Becomes Transparent: A great level of transparency is brought in the overall quality analysis and development process. The team gets a clear idea when a test fails, what is causing the failure and whether there are any significant defects. This enables the team to make a real-time decision on where and how the efficiency can be improved.
  • Cost-Effective Process: Since the bug count is low, manual testing time is greatly reduced and the clarity increases on the overall system, it optimizes the budget of the project.
  • High-Quality Application: Most of the process is automated, testers now have a lot of time to focus on important testing phases like exploratory, usability, security and performance testing. These activities can now be continuously performed during the delivery process, ensuring a higher quality application.
  • Happier Team and Better Product: Since the aim of Continuous Delivery is to make a product release painless, the team can work in a relaxing manner. Because of frequent release, the team works closely with users and learn what ideas work and what new can be implemented to delight the users. Continuous user feedback and new testing methodologies also increase the product’s quality.

 

Deployment Procedure:

  • Categorize your components in Pre-Manual, Metadata deployment and Post-Manual.
  • Perform Pre-Manual steps
  • Deploy Metadata components
  • Perform Post-Manual steps
  • Intitiate Data load.

 

Pre-requisites to implement CI/CD

Tools and uses:

  1. Gearset : Validate and Deploy components to target orgs.
  2. Jenkins : Schedule, Validate and Deploy components to target orgs
  3. Bitbucket / Git hub : Repository to store the components metadata.
  4. Git bash : Command line interface based tool to push your local changes.
  5. Source tree : Uset friendly interface to push your local changes

Know your tools:

  1. Bitbucket / Git hub : Bitbucket is a web-based version control repository hosting service owned by Atlassian, for source code and development projects. It offers free accounts with an unlimited number of private repositories (which can have up to five users in the case of free accounts). Bitbucket integrates with other Atlassian software like Jira, HipChat, Confluence and Bamboo.
    Git Hub is a Git repository hosting service, but it adds many of its own features. and provides a Web-based graphical interface.(GitHub is focused around public code, and Bitbucket is for private.)
  2. Git bash : Git Bash is an application for Microsoft Windows environments which provides an emulation layer for a Git command line experience.
  3. Source tree : Sourcetree is a free Git desktop client for developers on Windows. Say goodbye to the command line and use the full capabilities of Git through Sourcetree's beautifully simple interface.
  4. Gearset : Gearset is the only Salesforce release management tool focused on making your deployments succeed first time. Gearset automatically identifies and fixes common problems like missing dependencies, making it easier than ever to deploy. It is a browser based tool which requires a user license
  5. Jenkins : Jenkins offers a simple way to set up a continuous integration or continuous delivery environment for almost any combination of languages and source code repositories using pipelines, as well as automating other routine development tasks. It is a free and open source automation server.

Steps to follow:

Login in to Bitbucket using your Traction Atlassian acocunt
Setup a Project Repository in Bitbucket - Click here to know the steps
Share the repository with project team members
Create following branch under the master branch - Click here to know the steps

  • release/dev
  • release/qa
  • release/uat
  • release/stage (if required)

Master - Represents Production org
release/dev - Represents Dev Org
release/qa - Represents QA Org
release/uat - Represents UAT Org
release/stage - Represents Staging Org

Setup and authorize credentials of DEV, QA, UAT and PROD in gearset - Click here to know the steps
Setup a connection of each branch with there respective orgs in gearset. (Select branch as a source and org creds as a target). Click here to know the steps
 

Branching Strategy:

DEV:

Any code push to release/dev must be in a separate branch. Each ticket should be linked to a separate branch.
Branches in DEV should be created under release/dev and should be tagged as a feature branch
Example: feature/Ticket_number-Ticket_Heading
You can create this branch directly from JIRA board. Make sure the branch head is on release/dev
Once the code is pushed to the branch, create a Pull Request and add a reviewer to it for code review
image.png

Note: release/dev is connected with the gearset org validation which you had setup above in pre-requisites. As soon as the branch is merged in release/dev, validation will begin in few min against the dev. This validation will give you initial errors if anything is missing is branch which is required to deploy the components successfully in higher orgs or any error that you may face while validating against the higher org.
This validation is just to confirm that we are not missing anything related to the functionality.

QA:

Any code push to release/qa must be in a separate branch. Each ticket should be linked to a separate branch.
image.png
Pick the merge commits from the dev branch (older commits first, latest commit last) and push them to the newly created branch under release/qa.
Create a Pull request against the release/qa and merge it. As soon as the code is merged in release/qa a validation will run using gearset against the qa org and once the validation is successfully completed the same will be deployed to QA.

UAT:

Any code push to release/qa must be in a separate branch. Each ticket should be linked to a separate branch.
Pick the merge commits from the qa branch (older commits first, latest commit last) and push them to the newly created branch under release/uat.
Create a Pull request against the release/uat and merge it. As soon as the code is merged in release/uat a validation will run using gearset against the uat org and once the validation is successfully completed the same will be deployed to UAT.

Staging (if required):

Any code push to release/stage must be in a separate branch. Each ticket should be linked to a separate branch.
Pick the merge commits from the uat branch (older commits first, latest commit last) and push them to the newly created branch under release/stage.
Create a Pull request against the release/stage and merge it. As soon as the code is merged in release/stage a validation will run using gearset against the staging org and once the validation is successfully completed the same will be deployed to Staging.

PRODUCTION (Master):

Create a single branch under Master at the time of the production release.
image.png
Pick the merge commits from the stage/uat branch (older commits first, latest commit last) and push them to the newly created branch. Successfully validate your branch and create a Pull request against the Master and wait.
Once the deployment window is open, go ahead and merge the Pull request. Final validation will run after the merging of pull request and components will be deployed in production.