Applying Git standards to Salesforce ecosystem

One of the major benefits that Blue Canvas brings Salesforce developers is easy integration with Git.

Blue Canvas supports anything that standard Git allows; so you can use Blue Canvas with whatever Git flow your team is using today. Still, we’ve had requests to outline our vision of an ideal Git flow using Blue Canvas. So here goes. We will continue to update this doc as we talk to more users and learn about what works and what doesn’t.

One git-enabled Salesforce environment for Every Developer

Ideally, every developer will be able to use their own Sandbox or Developer Edition instance of Salesforce in order to do feature work. Because each Git branch on Blue Canvas is connected to a different Salesforce Org, this effectively allows you to keep Metadata in sync across your Orgs. You do all your feature development on a branch which mirrors production but which is crucially not production.

In an ideal world, one should never make changes directly in production.

Deployments to Sandboxes and Developer Edition Orgs are extremely fast using Blue Canvas – we’re talking seconds rather than minutes. This is great because it allows developers to quickly push their code changes to their Sandbox and do rapid iteration and debugging. These quick deployments are optimized to only upload the files that have changed since you last pushed. Unit tests are not executed automatically when you push to a development branch.

One team in synch, with easy synch from UAT into Sandboxes

Once you have your feature working well, we recommend checking for potential changes that other developers may have pushed to UAT or production while you were working, before pushing your own changes. With Blue Canvas this can be done with a simple git pull <uat-branch> or a Deployment Request from UAT into the developer sandbox. This ensured that your development code base is up-to-date and will save innumerable headaches later as you merge upstream.

This is especially helpful to keep track of declarative changes made through the web interface, such as field customization. Blue Canvas tracks these declarative changes automatically and commits them to Git. So if an Admin or business analyst has made a change that was not committed to Git, you will still be able to see that early by merging from UAT or Production into your Sandbox.

Pushing into UAT through Deployment Requests

Once you’ve pulled from UAT, you can push your changes upstream. Simply create a Deployment Request and push up to your target org. This will give your a concrete, visible package of changes on which other developers can comment. This will allow you to do one of our favorite best practices: code reviews!

In the ideal Git flow, a teammate will review your code here by looking at the Git diff.

Once the code has been reviewed, you can merge your changes from your development branch into the UAT branch. Blue Canvas will do an automatic deployment to UAT.

End-to-end Git-based flow to deploy to Production

Once you have deployed to UAT, you can do any further testing you may want to do here. This may include functional or user acceptance testing.

When you are happy with everything in UAT, you can issue a Pull Request to the master branch. The master branch always represents your Production Org. When the Pull Request is accepted. Blue Canvas will run your unit tests for you automatically and inform you if anything fails. Once tests pass we will deploy to production.

Production deploys on Salesforce are unique. Because of queueing and testing, it can take up to several hours to complete a production deployment. Accordingly, Blue Canvas will accept your push asynchronously and give you a notification telling you that a deploy has started. It will also give you a link which you can visit to track the progress of your deploy. We’ll notify you when the deployment is done by email or web interface.

Keeping UAT up-to-date

Once you’ve successfully deployed to production be sure to merge back downstream into UAT. Your UAT branch should always mirror master so that you are developing features on an environment that is essentially the same as production.