The case for investment in devops engineering is powerful. Devops is highly impactful because technology products change rapidly through the power of devops engineering. Product evolution based on user feedback lets enterprises compete and succeed with the power of software. Why can\u2019t we do the same thing for the thousands of developers and millions of people who use Salesforce products and services today? Fortunately, Salesforce Devops is now changing for the better with the emerging SFDX-CLI ecosystem.<\/p>\n\n\n\n
To help Salesforce developers and architects see the power of devops, I give some tips on basic Salesforce DX automation with BASH and MAKE in this post. Then, I discuss SFDX-CLI and its new plugin ecosystem and how it represents a key touch point between the Salesforce platform and open-source devops engineering. I’ll wrap it up with a list of the SFDX-CLI plugins that are interesting for Salesforce devops engineers.<\/p>\n\n\n\n
A devops engineer starts out small and builds up layers of functionality. Let us examine how those layers get built by looking at the heart of devops engineering: scripting.<\/p>\n\n\n\n
Linux scripts chain smaller parts of a system into a single command. Chains of small commands gives devops engineers the ability to iterate and compound scripted functions effectively.<\/p>\n\n\n\n
One of the ways of the devops is to stick with Ubuntu or Redhat Linux and BASH<\/a> for development and production scripting platforms. MacOS is close to Linux, but not identical. <\/p>\n\n\n\n VS Code Remote<\/a> provides for the use of standard scripting platforms by using powerful Linux servers on the local LAN in conjunction with off-the-shelf desktops and laptops. This doubles, at a minimum, the CPU power applied to a developer workstation which improves productivity. Using a standard backend service for developers also decreases onboarding time for new developers. Facebook and Microsoft developed VS Code Remote together<\/a> to help Facebook\u2019s SDLC process.<\/p>\n\n\n\n Devops engineering puts into order the most atomic components of a build process. Engineers start this process by automating functions with short scripts. <\/p>\n\n\n\n Scripts use platform CLIs like GitHub CLI<\/a>, docker-compose<\/a>, kubectl<\/a>, npm<\/a>, aws<\/a>, gcloud<\/a>, and sfdx<\/a> to deploy code, move artifacts, apply changes, and observe what is happening on the platforms. Small scripts are then used in other scripts. Eventually, the engineer has created layers of functionality built up into a master script, which accomplishes a high-level task with one command. A high-level function could be \u201ctake a new change set, run unit tests, run end-to-end-tests, deploy to 3 new sandboxes, send email to everybody about the status, and monitor the results.\u201d<\/p>\n\n\n\n The mark of a good devops engineer is to be a lazy typist who saves keystrokes in their day-to-day existence. That is where GNU MAKE<\/a> and a good Makefile become favorite tools. Here is a simple Makefile I made for an SFDX project. To use it yourself create a file called SFDX-CLI Scripting Essentials: Bash and make<\/h3>\n\n\n\n
Sample Makefile<\/h3>\n\n\n\n
Makefile<\/code> in the root directory of your project and paste in the contents. Change project-name<\/code> to your project name in Line 13. Create a permission set named ProjectPermSet<\/code> to support loading any custom objects or fields.<\/p>\n\n\n\n