Developing on the Salesforce platform can become complex to manage as your team and your projects grow and mature. At Atlassian, our internal Salesforce development team started five years ago with a single analyst making small changes and customizations to support a single department. Today, it’s a small team of developers, admins, and a program manager supporting multiple departments with varying needs for customizations of our Salesforce deployment. The team manages both types of Salesforce development: integrations and metadata changes from our developers, as well as the visual ‘point and click’ changes that admins can make directly in the Salesforce UI. Due to the complexity which can arise from all of this, the team is continually iterating on and improving their processes.
We have two separate sandboxes–Development and User Acceptance Testing (a full-data sandbox)–along with Production. Each instance is mirrored by its own Git repository to support backups, deployments, and team collaboration. The development environment is where developers merge their individual dev sandbox changes and run automated tests before the merge to User Acceptance Testing (UAT), where our internal users validate the correct behaviors before pushing to production.
Creating a Salesforce development workflow with Stash
Stash as an enterprise Git repository management tool makes it possible for the team to have fine-grained access controls for the various branches created by developers. We configured these permissions to create a workflow wherein developers branch, build, and deploy within their individual developer sandboxes, and must pass a set of strict criteria such as automated testing and code review (facilitated by Stash through a semi-automated process called a ‘pull request’) before merging back to main branch lines and fork syncing across the various environments. This fork sync is also what helps to manage the visual changes admins often make in the production environment through the Salesforce UI. Changes are auto synch’d back down to UAT, Development, and the developers’ individual sandboxes to ensure consistency across the environments as changes are made both upstream and downstream. This makes merging a much cleaner process and produces higher quality changes to the environment. This is a much more sophisticated and streamlined process than what typically exists in most Salesforce development teams outside of Atlassian.
Track, build, release, repeat
The team is constantly releasing small changes and improvements which are made possible through our continuous integration server, Bamboo, and they are able to trace back any changes made to any of the environments via JIRA. The team shares a unified view of this on their JIRA dashboard, which maintains the status of all issues/features: who is making changes and moving features forward, as well as the status of the builds and deployments.
Hear more about Salesforce development at Atlassian
To learn more about the journey the team has been on and the specific details of these processes and tools, check out our live session at Dreamforce: ‘Master your Metadata: Best practices for Versioning, Continuous Integration and Deployments’. We’ll also share how you can get a hold of the Cookbook the team has been writing to document these processes and best practices.
Join us at Dreamforce on Wednesday Oct 15 at 4:30 in the DevZone Theater – see you there!
The post Putting a lasso on the Salesforce development process appeared first on Atlassian Blogs.