A developer’s adventures in DevOps
“DevOps” begins with “Dev”, right? Must be my problem to deal with, surely?
Recently, my employer made the decision to move our existing build and deploy processes in-house. Previously, these processes have been managed on our behalf by our consulting partners, and it has worked pretty well. As our fledgling in-house development team has grown, however, so has the desire from management to bring more and more of the delivery lifecycle under our control. So armed with that most dangerous of things, a little knowledge, I’ve set out on a voyage of discovery on just how we get our Salesforce releases out the door…
Maintaining the status quo
The first part of the mission is to replicate what we have today, elsewhere. Our current toolchain is largely centered around moving stuff in and out of Git source control, hosted on Bitbucket. When changes reach the point that they are ready for QA, we simply merge changes into the QA branch of Git and Jenkins kicks off a build, using Ant.
I’ve done Ant before, I’ve used Git before — should be ok. In fact, it was easy enough to knock this chain together in one day and a fair chunk of that was waiting for a server to be provisioned by our IT department. Actual build was pretty quick, since we already had the Ant scripts from our existing implementation and an existing Bitbucket, so the tasks on the new server were:-
- Install Chrome — nobody wants to do this in IE
- Install Java Development Kit (JDK) 8 (the Java Runtime Environment, JRE, isn’t enough here)
- Install Apache Ant
- Install Git for Windows (which includes Git Bash, which is essential as you’ll see later on)
- Ensure all of those things are in the Windows PATH environment variable
- Install Jenkins
- Configure Jenkins with the recommended plugins
- Create a new Jenkins job
For our initial testing, we created a new Bitbucket repository that was a clone of our actual main repository — if we screwed up anywhere, it’s not going to break real systems. The first Jenkins job we created was pretty simple — pull the source code from Git and deploy it, using Ant, into a sandbox.
To access Git, we use SSH authentication for additional security, so we just use previously established credentials and add them to our new Jenkins config under the Credentials settings
As mentioned earlier, we already have Ant scripts for moving our code and config around — these scripts are the same for moving code in and out of our development sandboxes as they are for deploying code through Jenkins. We have some additional UNIX shell scripts (cos our consultants use Macbooks) to do some pre- and post-processing tasks and this is why we have Git Bash from the Git for Windows installation, so that we have a lightweight UNIX subsystem to run these same scripts on Windows.
By ensuring our Jenkins build box has these same Ant scripts available, we can craft our Jenkins job to pull the latest sourcecode and build it using our Ant Scripts. Testing today has done exactly that, so now we’ve proved it out, we can extend it for each of our environments as per our diagram earlier.
Taking it further
So now it works, just as it did before — but there’s room for change and hopefully improvement. The current build cycle is lengthy and takes a lot of hand-holding. Reviewing Git pull requests, resolving merge conflicts, validating builds before actually deploying them and more. It all means developer resource is chewed up delivering changes rather than developing changes.
To ease some of this strain, we’ve started looking at Salesforce DX. Apart from it being the recommended, approved, official way of doing things these days for the modern Salesforce developer, there are some very tangible benefits we foresee that will help drive our process to the next level.
- Scratch orgs — being able to pull code in and out of ephemeral, temporary developer environments a lot quicker is a big advantage
- Change tracking — when you push and pull changes to and from scratch orgs, for the most part it can see what has actually changed and only pull the differences. This in turn has the potential to help make more targetted, focussed Git commits
- Advanced tooling — the Salesforce CLI and the Visual Studio Code extensions thereupon are the preferred weapon of choice for Salesforce developers now, by recommendation. While they are heavily geared towards the DX way of working, they now (BETA warning!) allow you to work with greater efficiency with regular Salesforce sandboxes. This itself allows you to ease yourself gently into the DX way of working.
- DX also lends itself to a different philosophy of how to manage change in general — the idea is to break your Org into functional areas rather than technical ones, so that feature changes become more manageable. I shall expand upon this approach in a future blog post.
There are also some great third-party change management tools in the wider Salesforce ecosystem, such as Gearset and Copado, which allow a more visual approach to managing the lifecycle. You can find plenty of materials exploring and illustrating such tools on the web.
