In our previous DevOps articles we've discussed what DevOps is, why it's important, and explored an overview of the model.

This article gives a step-by-step walkthrough of what that process looks like in practice, filled with screenshots and comments along the way. It's designed to give you all the information you need to follow along and build your own DevOps workflow with Gearset.

This DevOps model has been tried and tested with teams of all sizes, from small development teams to global multinationals. For the majority of teams getting started with DevOps, source control, and deployment automation, we highly recommend you base your process off this model. In the words of Matt Avitable, a DevOps Architect from McKesson:

"With Gearset we have a fast, automated deployment pipeline which pushes changes into production throughout the week. My life has definitely gotten easier!"

Our scenario
The DevOps model
The 7 steps to the model
Common alterations
Summary

Our scenario

To set things in context, we’re going to follow through an example change from initial setup through to release to production.

In this scenario, we'll play the role of a Salesforce administrator charged with keeping our company's orgs running effectively. We've been tasked with adding a new field and setting the permissions appropriately to allow our support team to track when customers have urgent cases.

The systems we'll be using are:

GitHub for source control
A developer sandbox, a QA sandbox, and production org in Salesforce
Gearset for our DevOps tool

The DevOps model

Our example team have implemented an agile and robust DevOps process which follows the model from Gearset's whitepaper:

The process is broken down into 7 key steps which we'll follow through in this article:

Create branch
Refresh org
Compare & deploy
PR & code review
Continuous integration
Continuous validation
Continuous monitoring

1. Create branch

The first step to any new development work - whether it’s from a new user story from Jira, or just some tweaks to the permission model - is to create a separate feature branch to work in.

This gives us an isolated copy of our metadata that we can work on without concern for anyone else stepping on our toes or the world changing underneath our feet. It gives us a stable starting point, and stability is the key to smooth automation.

From the Compare & Deploy page in Gearset:

We'll select Source control as the source location, and select a source control account (in this scenario we'll be using GitHub).
Select our repository (in this scenario we'll be using gearset-salesforce-development), and choose the master branch as the starting point.

Click Create new branch from master and enter the name for the new feature branch - something descriptive like case-management-field would work well in this scenario.

Click Create branch.
Gearset will create our branch and select it in our repository.

2. Refresh org

Now that we've got a feature branch which contains all the latest changes from our master branch (and so, all the latest changes in Production), it’s worth doing a quick check to make sure our developer sandbox is up to date with anything else the rest of our team have been working on.

We can do this by running a comparison from the feature branch to our developer sandbox.

From the Compare & Deploy page in Gearset:

Choose the newly created feature branch as the source.
Select Salesforce as the target type.
Pick the developer sandbox that we're going to work in (either by selecting from the dropdown, or by typing the name and selecting from the list).

To make sure we're capturing all the metadata we need, we're going to use the Default comparison filter and click COMPARE NOW. For different projects or teams, we could opt to create custom filters which will allow us to narrow down the results and control what metadata types we see represented in the comparison.

Once the comparison completes, we can have a quick look to see if there’s anything new in our repository that we should add into our org before we start working.
In this example, there’s been a change to the CasePriority value set to add a new value called Urgent. This change was made by one of our team and was the precursor work to the feature we're working on now, so it’s a good idea for us to include this change in our org.

Select the change by checking the box next to its name.

Click NEXT.
The pre-deployment summary page now shows the changes we're about to deploy into our developer sandbox - a difference to our value set.

At this point, it's a good idea to add a deployment note, so we can easily track this deployment later on - this will feed into our deployment history in Gearset.
This is also where we could attach links to our Jira or Azure DevOps tickets and work items to link them to this deployment.

With the notes written, click DEPLOY NOW.
Gearset will push those changes into our sandbox, and we'll see a summary of the deployment.

This deployment is now stored in the deployment history in Gearset so we've got an audit trail of that release. The deployment name has automatically been carried through, and any notes will be included in the PDF report that can be downloaded from this page by clicking the PDF icon.

Now that our org is up-to-date with the latest changes and we've got a feature branch to work in, it’s time to start work on our feature!

3. Compare and deploy

In this scenario, we're just going to add a new field to the Account object so that our team can mark if a user has ever had an urgent support case. In the future, we could look at automating this with some additional logic, but to keep this article short we'll keep the changes simple.

We'll start by adding the field in our Salesforce development org, in the Account object.

Then it's time to set the permission model. In this case, we'll give access to this field only to three profiles: the Contract Manager , Solution Manager , and Admin and save.

Now that we've made some changes in our developer sandbox, it’s time to commit them into our feature branch so they’re stored in source control.
We'll do this by running a comparison from our developer sandbox to our feature branch (that we created in step 1). Select the developer sandbox as the source, and the feature branch in GitHub as the target for the comparison, and click COMPARE NOW.

In the comparison results, the new field and the associated field permissions are represented as two items in the table: a Custom field , and a Custom field permissions .

Selecting each item in turn allows a quick inspection of the XML to confirm everything is as expected - here we can see the details of the new field, including its description.

We can also see that the field-level security for the three profiles has been neatly collected into a single item ready for deployment alongside our field - no more manual profile changes here!

We'll select both those changes and click NEXT to view the pre-deployment summary.
This shows us the new field, the custom field permissions, and the three profiles that the field-level security will be stitched into automatically by Gearset.

We'll click DEPLOY NOW to move these changes into our feature branch.
Just like before, we'll get a post-deployment summary once it completes, and the deployment is stored in our deployment history.

4. PR and code review

So far, we've created our feature branch, partially refreshed our sandbox, made some changes, and tracked these in source control.

Now it's time to bring in one of the most important aspects of source control - code review. This helps improve code quality, catch bugs or vulnerabilities before they ship, gives a detailed audit trail, and also provides powerful tools for managing code conflicts.

Once we're happy with the changes we've made in our developer org and committed into our feature branch, it’s time to get them reviewed by our team and merged into the master branch so they can go out for testing:

From the deployment successful screen, click Create pull request.... (If we'd closed this page, we can get back to it by clicking View details from the deployment history)

Enter the name of the pull request (PR) and confirm the target branch we want to merge into is master.
Click Create pull request.

Gearset will now create our PR and give us a link to view it in GitHub.

Following the link, we can see our PR details in GitHub.

Before we're ready to get a review from our team, we should add some comments and notes to the PR. Adding in the comments makes it much easier for a reviewer to follow the changes and review them effectively.

Jumping across to the Files changed tab in GitHub, we can clearly see the new field and the associated FLS neatly stitched into each profile.

Going back to the PR, we can now assign a reviewer. This is the person who has the authority to review and confirm the changes are ready to be released. They can also provide feedback and suggestions on ways of improving what we've done.
In this case, our reviewer is one of our quality assurance engineers, Valerio. We'll set him as our reviewer in GitHub.

Valerio will now be notified of the PR and can review our code changes, leave comments, and approve them for release.
This process provides not just an audit trail, but detailed opportunity for peer review on code, as well as chances to spot bugs, improve performance, and get required sign-off for any release to be deployed.
Depending on the settings of the repository, an approved review may be required before any PR can be merged into master to ensure this critical step isn't skipped.

With the approval given, we can merge the PR. Once this happens, our changes get merged into the master branch, and the automated part of our release cycle kicks in...

5. Continuous integration

At this point, we've got our changes in the master branch in source control. Now, we need to get them out into a QA sandbox for testing, and then out to Production for our end users. This is where deployment automation comes in.

In line with the best-practice diagram, we've got two CI jobs set up in Gearset which are watching our master branch for changes. One (called Auto-stage to QA) will immediately deploy them out to our QA sandbox for testing and approval. The other (called Auto-validate to Prod) will build a validated package against production and hold for approval to release.

The key settings for the Auto-stage to QA job are:

Type: deployment
Source: our GitHub repository, master branch
Target: our QA sandbox
Runs job: when the source branch is updated
Run tests: Salesforce default
Other general settings have been left at their defaults
To find out more about how easy it is to set up CI in Gearset, have a look at our CI feature guide

When the PR was merged, the push event in the master branch triggered both jobs to run via a webhook. Looking at the CI jobs page in Gearset, we can see both of them have started running.

The Auto-stage to QA job automatically deploys the newly merged changes into our QA sandbox for testing. The history of the job is available for inspection at any point.
After a short run, the job completes and our changes are now out in the QA sandbox where they can be more thoroughly tested. And we didn't have to lift a finger!

6. Continuous validation

Meanwhile, our second CI job, Auto-validate to Prod, is busy working away building a validated deployment package against our Production org. This will allow us to perform a 1-click deployment to Production once we get approval from QA.

The key settings for the Auto-validate to Prod job are:

Type: validation (we selected this from the dropdown when clicking Add new job in the CI page in Gearset)
Source: our GitHub repository, master branch
Target: our production org
Runs job: when the source branch is updated
Run tests: Salesforce default
Other general settings have been left at their defaults

When the PR was merged, this validation only CI job also started running. Looking into the history, we can see that this also successfully validated the changes against Production.

Now all we need is testing approval from QA. Once that's given, we can deploy the changes out to production in a single click!
For additional review before the changes go out, we can click View summary for the list of items that were validated and cross-reference this with the other CI job.
Click Deploy from the CI job run history to kick off the release.

The deployment will then run and display the results. As it's already been through validation, Gearset can use the Salesforce Quick Deploy to avoid re-running tests and we're confident that the changes will move across successfully.

The deployment result is also stored in the deployment history in Gearset alongside the previous deployments.

And that's it. The changes are now live and in the hands of our end users in production! But there is one more step in our process that helps us keep track of all the changes going on in our environments.

7. Continuous monitoring

The final part of our process is continual monitoring for unexpected changes in our production environment.

Using a change monitoring job in Gearset, we're taking daily snapshots of our environment, and can see reports of the differences between each snapshot. This lets us track any changes made outside the standard deployment flow.

By running a snapshot immediately post deployment, we capture the new changes and ensure that any additional changes are then flagged as unexpected. This provides us with ongoing oversight into the changing state of our orgs and gives us confidence that any out of process changes will get captured and not lost.

The key settings for the Production change monitor job are:

Daily job run time: midnight
Org: production
Notifications: send email to [email protected] when changes are detected
Other general settings have been left at their defaults

From the Change monitoring overview page, click Back up metadata on the production monitoring job.
This takes a new snapshot which will be used as the baseline moving forwards.
Once the snapshot completes, we can see the changes we've just pushed are tracked in the job history as differences.

By clicking View history and then View comparison for the most recent snapshot, we can dive into the line-by-line comparison to confirm the only differences are the changes we just pushed.

From now onwards, any other changes made in Production will be caught the next time the job runs. This gives daily tracking alerts for Production.
If any unexpected changes are detected, they can be rapidly pushed down into GitHub so it’ll be tracked with any future development work, or even rolled back if we don’t want to keep it.

Common alterations

Although this model works for the majority of companies, in some cases you may need to make some alterations to the model as part of your implementation. A few of those alterations are detailed here, but we'll cover a couple of the key ones below.

Protected Master Branch Model

The most common alteration is to add a second branch into your source control system which sits between master (or 'main') and the feature branches. This is commonly called UAT/QA. Changes from feature branches are merged into UAT/QA , and then a CI job deploys changes from the long-standing branch into the UAT/QA sandbox. When ready for release, another PR is created to merge the full UAT/QA branch into master , and from there, the continuous validation job then prepares the release to your production org.

A summary of the Protected Master Branch Model is below:

Expanded Branching Model

When you want to more closely align long-term branches with your orgs, the Expanded Branching Model can be another great evolution of original Feature Branching methods. The model aligns branches in your source control system with the orgs in your usual flow, and allows more control over promoting the feature in turn to each environment for testing, before finally heading into master to deploy to production.

A summary of the Expanded Branching Model is shown below:

For more information on these models, along with the benefits and drawbacks, feel free to get in touch with one of our DevOps experts.

Summary

In this article we've explored what a modern DevOps model looks like in practice with Gearset and source control.

It has been designed to be read alongside our previous DevOps articles on what DevOps is, why it's important, and an overview of the model. For further reference, check out our whitepaper on version control for Salesforce, available from the resources page on our website.

If you've found this article helpful, confusing, or just have questions, don't hesitate to get in touch and one of our team will get right back to you.

Contents