The rise of GitHub as the most widely used version control system in the world — and its importance to open-source software — is a clear sign of the importance of version control. Indeed, the entire CI/CD (continuous integration and continuous delivery) movement would not be possible without source code repositories that are the first step of a CI/CD pipeline. Beyond CI/CD, modern software delivery is becoming increasingly declarative, with approaches like GitOps being the preferred way to deploy not just code but containerized infrastructure as well. These approaches are integral to automating and quickening the software delivery lifecycle and making it truly “continuous.” All of these developments outside Salesforce have an impact on how Salesforce applications are built and deployed. Not surprisingly, version control is becoming central to Salesforce software delivery as well. Salesforce CI/CD is no longer a new concept but one that every organization that builds Salesforce applications relies heavily on. There are mature CI/CD solutions purpose-built for Salesforce. As Salesforce teams adopt the principles of DevOps to build and ship applications, they see version control as a key enabler. In this article, we look at what version control is, its benefits, and how it is implemented for Salesforce application delivery.
What is version control?
Version control allows you to manage changes to files over time. You can use version control to version code, binary files, and digital assets.
— Chuck Gehman, technical marketing engineer, Perforce Software
Version control tracks changes to code, but importantly, it enables developers to collaborate around code while working remotely. In the current pandemic, this emphasis on remote development is all the more important.
Traditionally, software delivery teams would use unique versioned file names for saving code — this is a rudimentary example of versioning. Today, there are powerful tools that automate this entire process of saving new versions and making them easy to work with.
Versioning is not just for code but also for related artifacts like scripts, documents, and plugins. As the software development process becomes increasingly complex, versioning is essential to bring simplicity to an otherwise complex process.
Repositories are the backbone of version control. They are where code is stored. Changes from a remote repository are pulled to a local repository, and then new changes are pushed from a local machine back to a shared repository. The power of repositories is that they can be cloned, branched, merged, and compared. This is how version control enables collaboration at scale.
Top benefits of version control
Give developers immediate feedback
As developers commit changes to a repository, the version control system checks for conflicts in the code. The system can automatically fix some merge conflicts, but for others, the developer can view the list of conflicts and quickly fix them. This immediate feedback on code quality acts as a sanity check for code and reduces downstream issues.
Deploy frequently
Top-performing engineering teams were able to achieve higher throughput 8x deployment frequency and 8000x faster deployment lead times.
— Tali Soroker, content manager, OverOp
Version control improves the pace of development and the frequency of releases in many ways. First, it enables parallel development where more than one developer can work on the same repository separately, and finally merge their changes. Second, it reduces the time taken to fix issues as there is less back-and-forth between Dev, QA, and Ops teams. Issues are caught early and fixed before they impact users.
Ship reliable applications
Version control has multiple levels of checks before code is deployed into production. Apart from the initial check for conflicts, there is room for QA teams to do a code review before giving the green light on new code. As Dev and QA teams collaborate using the same version control platform this brings consistency and helps QA to “shift-left” as is expected in DevOps.
Developers in focus
Developers are becoming central to the entire software delivery lifecycle. With the shift-left movement, we see QA and Ops teams moving closer to Dev teams and including them as part of testing and managing applications in production. Version control, which is based on source code repositories, enables this shift-left toward developers. It empowers developers to have a say in what happens downstream to the code they write. It also unifies processes across the three teams — Dev, QA, and Ops. We’re seeing Salesforce developers become more important to the software delivery process, and version control supports this trend.
Salesforce-centric version control
Salesforce has some unique features that require a slightly modified form of version control. Along with source code repositories, Salesforce also includes sandboxes, that have a lot of similarities with a repository but are still different.
Salesforce sandboxes
A sandbox in Salesforce is a copy of the production Org. There are different types of sandboxes — full, developer, developer pro, and partial data sandboxes. Only the full sandbox contains a copy of all data and metadata of the production Org, the others contain all metadata and only a subset of the actual data. Salesforce software delivery teams use metadata-based sandboxes according to their need.
Most successful companies we talk to are finding that every developer should have their own sandbox. This is great for auditing and keeping track of work. You should also have an integration sandbox, preferably a partial or full copy sandbox, that can be used to merge code into as features are developed.
— Alex Brausewetter, founder, Blue Canvas
These sandboxes exist alongside repositories, and conflicts can arise between sandboxes and repositories after every commit. Then, when deploying the changes, teams can choose to deploy from a sandbox or from a repository. With its more powerful features for conflict resolution and collaboration, it is better to deploy from a repository than a sandbox. However, having both options is helpful.
There are usually multiple sandboxes and repositories for each team and each user. Managing all of them can add to the overhead and become counter-productive. This is why Salesforce DevOps teams should give thought to their sandbox management and repository management.
Version control and sandbox management for Salesforce
Solutions like AutoRABIT include features that help with managing both version control and sandboxes. For example, AutoRABIT enables “auto-commit” of changes from a source code repository. This automation not only saves time but it also reduces the number of errors that can creep in when moving code around.
When it comes to sandbox management, AutoRABIT offers synchronization of sandboxes across different locations. It compares different sandboxes and highlights the changes and minor variations between them. Further, it improves sandbox management with logs and reports on the number of deployments and errors and points back to which specific changes broke something. This is powerful when dealing with sandboxes in large organizations, which can easily get out of hand.
Version control: A must for Salesforce DevOps teams
Version control is an essential part of software development. This is true, especially for Salesforce DevOps teams. They need the power of a version control system and a sandbox management solution to deliver software at the scale and velocity that today’s market demands. This would put developers in the driver’s seat and unify complementary teams like QA and Ops to realize the full potential of DevOps for Salesforce. If you’ve already begun adopting DevOps practices to build Salesforce applications, you need version control and sandbox management.
Featured image: Pixabay
Great article, but you did not mention Copado.