Salesforce Continuous Integration is an integral practice when keeping your Salesforce Applications up to date. It allows developers to work in the same place, regularly integrating their code changes in a code repository. One tool that can help streamline that process, is GitHub. Since its conception in 2008, GitHub has become the world’s largest open-source platform for hosting software development. Which allows developers to collaborate with each other from anywhere in the world.
Red Argyle has been using GitHub to develop our projects since our conception 10 years ago. Continuous Integration of Salesforce on GitHub can create an easier experience for developers working in Salesforce. As well as end-users in the Salesforce tool, the developers build. Red Argyle has delivered hundreds of Salesforce projects, all built by our developers on GitHub. We believe we have learned a thing or two about how Salesforce Continuous Integration on GitHub, and want to share some of what we’ve learned.
There is a lot to unpack here. How GitHub itself works, what Continuous Integration is, how it benefits in Salesforce, and much more. Instead of forcing it all into one post, we are going to break it into a three-part series. Beginning with a high-level overview of Continuous Integration and Github. Throughout this three-part series, we will provide a greater in-depth guide for implementing Continuous Integration on GitHub.
The goal of this series is to drive innovation and technological maturity for anyone wanting to enhance their Salesforce org. By the end of this series, readers will be able to implement Continuous Integration for their Salesforce org. As well as advocate for the benefits Continuous Integration can bring to their Software Development Lifecycle.
Continuous Integration
What is it
From Atlassian.com:
Continuous integration (CI) is the practice of automating the integration of code changes (Metadata for Salesforce) from multiple contributors into a single software project. It’s a primary DevOps best practice, allowing developers to frequently merge code changes into a central repository where builds and tests then run. Automated tools are used to assert the new code’s correctness before integration.
A source code version control system (Github) is the crux of the CI process. The version control system is also supplemented with other checks like automated code quality tests, syntax style review tools, and more.
Essentially, Continuous Integration is a practice that keeps the production org’s metadata in a deployable state by using automated tooling. It automates frequent checks of the metadata and codebase, to the standards that are set for a given repository.
Benefits in Salesforce
Speed to Market
Whether it be a Salesforce Community or internal Lightning application, the products we’re building on the Salesforce platform have a direct effect on revenue. The sooner your Salesforce functionality is deployed, the sooner your stakeholders are generating more revenue for your business. Continuous integration has a direct impact on speed to market and reduces the amount of features that are sitting in a queue waiting to be deployed.
Security
Salesforce provides a robust security layer around their database to ensure that every user is only able to see the data that pertains to them. Setting up and maintaining the security model is critical for an org. Continuous Integration ensures that security requirements have been followed during development by performing automated analysis prior to merging or deploying metadata into production. This automated analysis is helpful in detecting security risks that may have been overlooked during development.
We will cover the implementation of meta-data and code scanners we use in the upcoming articles.
Technical Debt
Technical debt is the incremental cost and loss of agility for an organization. The longer a Salesforce org has been around the more risk it has for building up technical debt. In Salesforce terms, technical debt is the build-up of undesirable code, packages, or metadata. All of which, will eventually need to be addressed in the future at a cost significantly higher than if it had been rectified at the start. Using Continuous Integration, code, or metadata that does not follow Salesforce best practices and security requirements, is identified early on and remediated prior to migrating up the Sandbox/Production Org path.
Technical debt as it relates to a Salesforce org applies to all aspects of an org and goes far beyond code. Packages, Process Builder, Flow, Workflow Rules, Profiles and many other metadata types can grow in complexity over time. If not monitored, it can significantly add to the technical debt of an org.
Regression Testing
Continuous Integration enables an org to have a standard way of performing regression testing. This can be useful whenever a need for regression testing comes up such as, prior to a new Salesforce release or feature release. The sooner in the development process, a regression bug is found, the lower impact in cost it will have to eliminate regression.
Suture Automated Tooling
Standing up a Continuous Integration process puts the architecture in place for adding additional automated tooling in the future. This additional tooling can potentially include scanning of all metadata prior to a production deployment, including configuration metadata ex: profiles, permission sets, Process Builder, etc. As an example, the potential exists to create a Risk Inspector type of scan that can be used to flag high-risk profile settings prior to production deployment.
Release Rate and Deployment Readiness
Continuous Integration and a solid Sandbox strategy can keep your source code and metadata in a release-ready state. Release agility is necessary for the critical business orgs we support.
In our Continuous Integration Pipeline, we validate our deployments to the upstream sandbox once a feature or enhancement has passed our standards and automated testing checks.
Stay tuned for our next articles to learn how to validate your source and metadata to the promoting org/sandbox!
Team Standards and Accountability
Have you ever been so lucky as to step into a coding style and standards conversations with passionate developers?
These conversations are important but can easily go off the rails and provide limited benefit given the amount of time to reach alignment across a team.
What is Github?
Github is the world’s largest open source platform where more than 56 million developers are building software together.
From github.com:
Github is a code hosting platform for version control and collaboration. It lets you and others work together on projects from anywhere.
Here at Red Argyle we use Github as a collaborative platform to drive Salesforce Development best practices and source-driven deployments. Our Salesforce Orgs’ metadata and code assets are stored in Github Repositories. Our large team of developers work in tandem on Salesforce features. They’re able to do so effectively in large part due to the behaviors Github provides and enhances.
Without diving into our Gitflow branching strategy, behaviors such as release branches and code reviews are just a few of the practices that thrive in our Github repositories. Code Reviews, or a peer review process in which developers review lines of code for a feature preparing to be released, is a great culture enhancing behavior we follow. When developers review code to align to best practices and patterns, it drives team unity, a more stable product, and highly engaged engineers.
Github is also the platform many universities and colleges have students gain experience with Git and Code reviews for their class projects. Red Argyle has a very active Co-op program with the Rochester Institute of Technology. Each student we talk to is already well versed on the GitHub platform and familiar with our branching/review path. These ready candidates aren’t just unique to RIT, and in most cases will quickly ramp up to a Salesforce development team that uses Git and GitHub repositories for code reviews and source control.
Salesforce Continuous Integration has proven to be an path forward to utilizing and sustaining the Salesforce platform. Continuous Integration is a process with many layers as to how it can be beneficial in Salesforce. The next part of the series will be focused on a more technical description of GitHub and its advantages. As well as how to get started using GitHub.
Stay tuned for the next two installments of this three-part series. If you want to talk to us or have any questions, contact us!
