How Atlassian uses Bitbucket, JIRA and other cloud tools to help Salesforce developers collaborate.
In this article, we'll dive into the insights shared by Melanie Wright and Sheldon Callahan from Atlassian during their talk at Dreamforce about effective Salesforce development strategies. We'll explore their development principles, the importance of source control, sandbox strategy, and how to manage code collaboration challenges. By the end, you'll understand how to streamline your development workflow, reduce code clobbering, and foster better collaboration within your development team.
Here are our 5 Key Takeaways:
Dreamforce is one of the best places to learn from others about how they are doing Salesforce development. This year there were hundreds of developer sessions that covered a range of topics including continuous delivery, version control, Salesforce DX, automated testing, Lightning and more.
One of the best talks from all of Dreamforce was given by Melanie Wright and Sheldon Callahan of Atlassian titled: Keeping Dev in the Cloud: Best Practices for Salesforce Cloud Collaboration.
The three principles of Salesforce development at Atlassian: one feature at a time, isolate your work, and automate everything.
Atlassian is renowned for their Salesforce development workflow as well as their products that facilitate collaboration. In this talk, Sheldon and Melanie explained their workflow in detail and highlight some great cloud tools that facilitate it.
Given that there are thousands of Dreamforce sessions to watch, we thought we’d offer a quick outline of the talk so you can get the high level points quickly. The video is available here and is worth watching in full.
Sheldon acknowledges a major challenge right off the bat: it can be really difficult to do Salesforce development in a collaborative way. Devs and admins have to work hard to stay on the same page much of the time. “I would make a change that would reflect on [my colleague’s] Org and our changes would clobber each other,” Sheldon said. The way Salesforce deployments work today makes code clobbering a real issue. The Atlassian workflow (and Blue Canvas) strive to avoid this.
The other major challenge Sheldon describes occurs when an admin makes changes in production or more generally through the UI. When changes are made through the UI it can be hard for developers to see what has changed. For the vast majority of Salesforce instances, these changes are never tracked in source control and so cannot be accessed by developers. Handling merge conflicts becomes a nightmare.
In order to address these challenges, Atlassian has implemented 3 Principles of Salesforce Development:
Melanie calls this “feature driven development”. When multiple developers (and admins) are working the same sandbox on different features it gets confusing. It’s hard to tell who changed what and why. By only working on one feature at a time, it is easier to track what is happening and avoid messy merge conflicts.
Every developer should be working in their own sandbox. This ensures that no one is colliding with others as they develop new features.
Atlassian tries to automate everything that they possibly can. Of course, it’s not easy to build a fully hands-off process, but the goal is to take it as far as they can reducing manual tasks. They automate metadata and configuration changes. They even automate things like populating pick list values so that the team can maintain velocity and stays fully focused on coding.
Melanie and Sheldon note that Salesforce is all about the cloud. And so it makes sense that your development practice should be cloud-based as well. They leverage tools like Cloud9 IDE – a cloud-based code editor – and Bitbucket Pipelines – a cloud based CI extension for Bitbucket (which is itself a cloud based version control system). This all in the cloud approach makes it easy to setup and maintain a good workflow and it only needs to be set up once.
One of the fundamental problems we hear time and again with Salesforce code collaboration is that if someone is working in the same sandbox as you are, they can easily overwrite your changes. This is known as “code clobbering”.
To solve this problem, Atlassian recommends setting up your Orgs strategically: In addition to your production Org (which should always remain as bug free and well tested as possible), they recommend a UAT or “staging” environment that closely mirrors whatever is happening on production. Atlassian uses a “full copy sandbox” for their UAT environment. The UAT environment is where final testing happens before moving to production.
Devs create their own feature branches from the Dev repo and work on a feature. They use their own sandbox to write the feature and test it out to make sure the feature is working as expected. When they are happy with their code, they can merge it back into the Dev repo’s master branch.
They also have a Master Dev Org which in turn is a copy of their UAT environment. This is where they merge code from different developers and make sure that things are working well before pushing to UAT for final testing. It’s also the place where declarative changes are often made, if they are global.
Finally, every developer should also have their own personal sandbox, which is a copy of the Master Dev Org. This is for experimentation and specific feature development.
Unsurprisingly, Atlassian uses Bitbucket for source control. They recommend using Git because it allows you to easily rollback if problems arise and allows people to isolate their work. This is where “Git really shines”.
Every feature deserves it’s own branch. This allows you to isolate code and avoid affecting other users.
The master branch is always stable in the Atlassian workflow. You create a new branch for a new feature and make various commits on that feature branch in order to show the work you’ve done. When you are happy with your changes you then merge it back into the master branch.
Atlassian also uses a Git forking strategy to mirror their various Salesforce Orgs with different Git repos. There is a production repo that is tied to the production Org. They fork that production repo into a UAT repo which is tied to the UAT Org. And finally they fork the UAT repo into a Dev repo which is tied to the Dev Org like so:
Using Bitbucket allows for two key parts of the Atlassian Salesforce developer workflow: code reviews and pull requests.
Setting up your sandbox and source control strategy is only half the battle. You need people to follow a specific workflow in order to avoid the challenges around code clobbering and general confusion.
Devs create their own feature branches from the Dev repo and work on a feature. They use their own sandbox to write the feature and test it out to make sure the feature is working as expected. When they are happy with their code, they can merge it back into the Dev repo’s master branch. This sets off two important processes: a code review and a battery of automated tests.
Another developer should always review the code before it can be merged into the UAT branch for further testing. This is important because it ensures high quality code and empowers everyone on the team to know what’s going on with various features.
While a developer is reviewing the code manually, the code can be tested automatically. If something is amiss you will be notified via your automated tests. This is far more reliable and faster than performing manual testing. If someone else has deployed something to the Dev branch which is conflicting with your changes you’ll be notified at this stage.
Once the code review is done and all tests are passing you can merge up to the UAT branch. An Ant script then deploys the code from the UAT repo to the UAT Org. Further testing can occur here. Once it’s tested and approved you can safely deploy to production.
Having all your developers working independently in this workflow is great. But what if your team includes Awesome Admins?
In the Atlassian flow, Admins can make changes directly in the Master Dev Sandbox and trigger a build manually. Metadata isn’t automatically picked up, so the admin must add any changes to the package.xml. They can include a commit message at this point. From there things generally go the same way. Automated tests can run on the build trigger.
Though not mentioned in the talk, this is where Blue Canvas can be of particular help. Blue Canvas automatically picks up declarative changes made through the UI and commits them into Git so that developers and admins can work more harmoniously. Learn more about Salesforce Version Control.
The talk covers a lot of other topics including handling destructive changes, other branching strategies, and other cloud based tools. It also provides more detail on the specific Bitbucket Pipelines and JIRA features that Atlassian use in their developer workflow. We at Blue Canvas love what Atlassian is doing and want to salute and thank Sheldon and Melanie for making this all publicly available.
