At PwC we use continuous integration whenever we can. It helps us to manage our code base when we have multiple developers working together on large scale projects. Developers submit their code to the shared Git repositories every evening before they leave or multiple times during the day.
Each commit is then verified, merged and deployed by our Jenkins setup. But in our current setup we still have a couple of problems that need solving. I was very glad to see the Salesforce DX announcement in the Dreamforce 2016 Developer keynote.
So what is Salesforce DX about? First, It’s about shifting the app’s “Source of Truth” from the Salesforce org to any version control system (we use Git). So that means our code on Git is master and we push everything from Git to Salesforce.
But it’s also a CLI that enables you to write scripts to automate all kinds of stuff. Things I saw were things like assigning permission sets “sfdx force:permset: assign -n DreamHouse” or Pushing source metadata changes “sfdx force:sfdc:push -w”. I like to think that in the future they would add a statement for about almost every action you could think of.
The biggest news for developers was without a doubt the introduction of the scratch orgs. This is a brand new org type built specifically for developers and automation. They are built quickly from your source (Git) and metadata, making it easy to build your app consistently over and over again. They are always empty and do NOT have any data. They execute in seconds and you can define your org shape in a JSON file. More importantly, Scratch orgs are NOT a replacement for sandboxes. All sandboxes now act as UAT or Staging Environments.
Although we are currently still a couple of Salesforce releases away from a public beta, it will have a big impact on the new Salesforce developer experience.
How we are doing it now
At PwC we currently implement continuous integration at our larger projects. Our developers use separate Git branches that are automatically merged by our Jenkins setup every day. This way we make sure that there are no conflicting changes and the merge doesn’t break the build.
As you can see we need to have a dev and test sandbox for each branch/project. We don’t really use branches for features but use them to group features in a project. One team works on one branch/project and another team works on another branch/project. Some people even work on both so you can imagine that it can become complicated.
Every night Jenkins tries to merge the available branches/projects into our dev integration sandbox so that we get notified when branches/projects are not able to merge and that they need intervention. If merging goes well Jenkins pushes to our full test acceptance sandbox and later to production.
The problems we have with this is that we can not separate feature development. We also have to set up a whole lot of sandboxes and jenkins jobs before we can even start development and we have to intervene quite often for merge issues in the morning.
Let’s see how that would work with Salesforce DX.
How do we want to do it with Salesforce DX?
Now we have the explanation out of the way we can see how we would use the DX and how it would change our development & deployment process. Below is the draft of how we could use it but the possibilities are endless.
With the Salesforce DX in place developers just need to clone the master or their fork from the master. Once they do that they can fire up a scratch org to test their new code. They can create as many branches as they want and as many scratch orgs as they want. All by just executing scripts. Once they feel their development is working and up to standards they can submit a pull request to the master.
This is where the release manager comes into place. The release manager will see the pull request in the release management tool (currently based on heroku pipeline), will test to see if it merges with the master and will be able to promote the pull request to the full test sandbox and later to production.
So, why are we excited about the new Salesforce DX?
We are very excited by all of this and the possibilities it’s going to bring for development on the salesforce platform. We’ll be able to separate feature development now and easily test them in scratch orgs. We’ll no longer have to go through the repetitive process of setting up and syncing sandboxes anymore. By using version control on all our code and metadata today, we’ll be able to be more efficient in our development and testing tomorrow. Very nice Salesforce! Very … nice!!
I recommend all Salesforce Developers who were not at DF16 to watch the live recording with Wade Wegner here.
This article was written by Steven Hugo.
