In the realm of DevOps, efficiency and automation are paramount. Many routine tasks, whether deploying changes from a Git branch to a Salesforce org or ensuring the ongoing health of Apex code, can become repetitive and time-consuming. Copado Essentials Plus addresses these challenges with Continuous Integration (CI) Jobs, designed to streamline and automate these critical but monotonous tasks.

CI Jobs in Copado Essentials Plus are automated processes tailored to enhance the DevOps workflow by regularly executing predefined tasks. These jobs can be configured to run on a schedule, triggered by specific events via webhooks, or initiated through direct API calls. This automation capability not only saves time but also increases accuracy by reducing the potential for human error.

CI Jobs are versatile and can be employed in various scenarios, including but not limited to:

- Automating metadata deployments from one environment to another,

- Performing regular health checks on your codebase,

- Synchronizing changes across environments,

- Backing up configurations and metadata periodically.

Much like how you would adjust the environment access levels through Org Sharing, by default, access to trigger these jobs is restricted to team members with Deploy permissions, ensuring that only authorized personnel can execute or modify the jobs. This introduction will guide you through setting up and leveraging CI Jobs to maximize your DevOps efficiency and effectiveness.

To help get started with CI Jobs, we've outlined how to perform some of these common use cases below.

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.

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.

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.

Note that when using the one of the first two Git source options, the "Inclusion" feature is hidden (in the "advanced options" screen shown below). You can, however, use the "Exclusion" feature in all four Git source deployment options.

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.

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 its corresponding Salesforce environment listed as the target, and the option to "trigger by git commit to branch" having been selected.

Note: Currently, dynamic/variable source branches are not supported when configuring CI Jobs.

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.

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 in both the target environment and source branch of the CI Job.

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 the Rest API Enable 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!).

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.