Skip to main content
CI Jobs Overview

How to set up Continuous Integration Jobs (CI Jobs) for various use cases.

Garrett Meeks avatar
Written by Garrett Meeks
Updated over a week ago

Many tasks involved in the DevOps process have a tendency to be repetitive, to say the least. These tasks can range from additional steps to complete a deployment from a Git branch to the target Salesforce org, or something as simple as regularly making sure your orgs have "healthy" Apex code within them. Fortunately, Copado Essentials+ can help to automate a lot of these redundant and monotonous tasks by allowing you to take advantage of CI Jobs.

CI Jobs are "Continuous Integration" jobs, which are meant to automate tasks that would otherwise need to be performed regularly, through scheduling action frequency, utilizing web-hooks to trigger an action, or through triggering an action through the Rest API. To help get started with CI Jobs, we've outlined how to perform some of these common use cases below.

Scheduling CI Jobs for Repeat Actions:

Scheduled Tests:

  • Daily/Weekly Validations:

CI Jobs can be utilized to run regular tests and make sure that the Apex code within your orgs maintain proper coverage, as a way to monitor the "health" of your code. These tests are performed as part of a Validation that can "include unit test code coverage" in the result, which you can monitor over time in your build history, or you could simply schedule Static Code Analysis to run. Take a look at this article outlining how to set up scheduled test executions, but it's worth noting that the source org in this instance is arbitrary, as the tests will be run in the target environment, and no components need be selected so this can test the entire target environment.

Automate Regular Metadata Backups to Git:

  • Regularly backup org metadata to Git

As part of a Work Item or Deployment, you have the option to commit changes between environments to a Git repository. However, changes that are made within an environment and not deployed run the risk of never making it into your Git repository. This could resemble changes that are in-progress in a developer environment, or metadata changes can inevitably originate in upstream environments without deploying through a defined process. Without a way to backup these changes, the metadata is vulnerable to being overwritten during a deployment, or more easily erased during a sandbox refresh since the only record of these components existing is in the environment they originated in. To help with this omission, a CI job can be leveraged to make regularly scheduled deployments directly to Git from any or all environments needed, helping to ensure you're following best practices. This CI Job can run on any schedule needed, or be manually triggered, to commit any in-progress metadata to Git without the risk of prematurely deploying to a Salesforce environment, or having changes be overwritten. To setup regular backups to your Git repository, navigate to the CI Jobs tab and select "New Job". On this screen, fill in the details of the job, including selecting the source Salesforce org and target Git branch as demonstrated below, where the Action to "Commit to Git" will be triggered from the Dev 2 Salesforce org to the Dev-2 branch in GitHub:

Once the source org and target branch have been selected, along with specifying the frequency the job should be executed, click "Save". At this point you'll be able to select the specific components that you want to regularly backup to your Git branch, and if you want to deploy everything, choose the "Wildcard" component type and select all. As a final step, under the "Deploy Options" tab, choose "deploy directly to target branch" within the Advanced Options.

Note: Currently, Copado Essentials+ is unable to support dynamic CI Jobs to auto-select net differences between Salesforce environments. This is planned for future releases, however similar results can be achieved using the method specified in the next section.

  • Regularly sync lower environments with Production through deploying differences between Git branches

There are several situations where back promotions are needed, and these can be achieved with both Deployments and Work Items. However, ensuring your environments are in sync with the latest changes in production can become a tedious and repetitive task. Having multiple developer environments that need the latest changes from production requires several independent deployments, carefully curated to ensure that only the net differences are being deployed and that any in-progress work is not overwritten. In conjunction with the method listed above, Copado Essentials+ can help to automate this otherwise repetitive task by deploying the net differences between two Git branches to a Salesforce environment. To do so, a Git branch will need to be set as the source of the CI Job, with the Salesforce environment as the target, and "Deploy" as the Action.

After specifying the details of the job, within the "Deploy Options, under Git source, select the option to "deploy differences between master and [branch x]". With this option, the comparison branch will need to be specified manually.

Once saved and triggered, the CI Job will compare the branches specified and deploy net differences between to the target Salesforce org listed in the details of the CI Job.

Trigger CI Jobs Using Webhooks:

  • Triggering CI jobs through Git branch merges

At Copado, the most common use case for CI Jobs is automatically deploying changes from a Git branch to a Salesforce org through the use of a webhook. As opposed to previous methods listed, this CI Job is not triggered on a regular schedule, but by an action. As shown below, a Git branch is specified as the source, with it's corresponding Salesforce environment listed as the target, and the option to "tigger by git commit to branch" having been selected.

With this option selected, and after setting up a webhook within you repository, a Deployment from Essentials+ to Git will create a feature branch that can then be utilized as part of a pull request. This pull request can then be completed as desired, ultimately merging the changes into the target branch and triggering the webhook that was created. Once triggered, the CI Job will initiate momentarily and, based on the selected Git Source behavior, run the CI Job as specified. Most often, the option selected is to "deploy files committed since the last successful build", which will ultimately deploy everything waiting in the build queue within Git for that branch.

Understanding "Incremental Diff" deployments

An incremental build contains only files committed since the last successful build which is indicated by a build marker. Every time a deployment is successful, the build marker is automatically moved to the head of the branch.

This means the pending change queue is reset after every successful deployment, and no manual intervention is required in general. However, if you ever need to change the build marker to a specific point, simply edit Deploy Options and point to the new commit ID. Note that for an incremental validate CI Job, a successful validation does not move the build marker automatically. The build marker for a validate CI Job is only moved when the equivalent deploy action is executed successfully.

Additionally, with a Git repository as the source of a CI Job, a rollback is available for completed deployments to revert any changes that were unintended.

Trigger CI Jobs Using the Rest API:

  • Triggering CI jobs as an "outgoing webhook" within Essentials

Some situations may require a more inconsistent CI Job to be triggered, such as only when a deployment is made to another environment. Examples listed above for backing up metadata or triggering a back promotion are great use cases for this when a set schedule isn't needed. To utilize this feature, within either a Deployment or Work Item, navigate to the "Deploy Options" tab, and within the Advanced Options, check the Outgoing webhooks box.

Checking this box and clicking save will create a new "Outgoing Webhooks" tab within your deployment, but before filling out that tab, a couple steps need to be taken. The next thing to do would be to generate an API token from within the settings of Copado Essentials+, as shown below. Copy this API Token and save it, since it will be used later as the "Password" for the outgoing webhook.

Next, navigate to the CI Jobs tab, where you can create a new CI Job, specify the source and target environments, select the Action to be completed, and enable to "Rest API" checkbox. As shown below, we'll use the example from earlier where the CI Job will backup changes from the Dev 2 Salesforce environment to the Dev-2 branch of GitHub, however this time it will be triggered via the Rest API.

After enabling the "Rest API" box, click "Setup API" to access the menu shown below. Outgoing webhooks only support the POST Request, so the URL listed in the red box below is what would be needed to trigger this CI Job. This POST Request URL is what will be used for the Webhook URL in the "Outgoing Webhooks" tab of the deployment.

As a final step, on the "Outgoing Webhooks" tab of deployment being created, input the information that has been gathered from the previous steps. The POST Request URL will be used as the "Webhook URL", your Essentials+ Username is needed for the "Username" field, and the API Token generated will be used in the "Password" field.

Now, the CI Job using the Rest API will be triggered by the outgoing webhook immediately following the deployment that has been setup. This will allow for a quick and easy way to trigger any CI Job from a Deployment or Work Item, with the only pre-deployment requirement being to use the appropriate POST Request URL within the "Outgoing Webhooks" tab (to ensure the right CI Job is triggered!).

  • Triggering CI Jobs through an external system, outside of a webhook

As a final use case for CI Jobs with Copado Essentials+, the Rest API can be triggered from an external source without the use of a webhook. This functionality is for teams who may have a process within another system, or another third-party web application, but need to utilize automation to deploy to Salesforce. By utilizing this feature, Copado Essentials+ can help to deploy changes from one Salesforce environment to another when triggered, or between a Git repository and Salesforce. In addition to the POST Request URL mentioned previously, this method would also allow for external systems to use the GET Request URL to check the status of a CI Job.

Did this answer your question?