Salesforce SDLC Nomenclature: Adopting the Ways of The Devops
👉 Check Use the Salesforce Devops Segmentation Model for IT Success for a revision to the Salesforce devops industry segmentation model. 👈
A Definition of Salesforce SDLC for Solution Architects
The #1 challenge to Salesforce architects, developers and delivery managers today is to produce results faster.
As I write more about the Salesforce Software Developer Lifecycle (SDLC) in order to help advance this engineering practice, I need to set some ground rules on how to classify the terms, software, vendors, and actors that make up the Salesforce SDLC ecosystem. I will wrap up this nomenclature tutorial with some practical guidance on how to build an SDLC implementation.
Salesforce SDLC – What Is That?
The term Software Delivery Lifecycle (SDLC) represents the entire practice of software delivery management. If you are reading this, then you are (or wish to be!) an architect for a major software project tasked with fulfilling the functional goals of an enterprise program. That program is likely to have many stakeholders, including customers, investors, enterprise staff, and project staff.
Based on those criteria, an SDLC implementation must encompass the software, tools, systems, people, and best practices used by all the stakeholders of the program to achieve the delivery of the software’s functionality to the enterprise.
The Pipeline Model, But Faster
But how do you build an SDLC implementation using devops engineering? The premise of SDLC as a software pipeline is simple. It starts when a developer commits new code to a source code repository. The invoked processes compile, test, secure, and assemble deployment artifacts. Docker containers and Salesforce change set are deployment artifacts.
One cycle of the SDLC process completes when the artifact deploys to a production environment. When running at “devops speed,” daily deployments to production should be possible.
Most discussions about SDLC involve a version of this flow diagram.
The flow diagram is deceptively simple, because an SDLC implementation is usually extraordinarily complex. The flow diagram does not guide an architect towards a solution.
Time to Stack the Salesforce SDLC Solution
Another way to study SDLC is to group the tools and actors by ascending levels of functionality and descending levels of granularity, like a TCP/IP or OSI networking architecture stack.
Here are the explanations of these layers, including examples of tools and actors, starting from the bottom, and going up the stack.
- Repositories & Release Management – This stack component is usually a Git-compatible server that supports branching and pull requests for code review and release management. In the case of Salesforce, the artifact repository is frequently a sandbox or developer org instead of a “real” repository. GitHub is the leading commercial platform for repository management.
- Platforms, Services, Testing and Security – This part of the stack consumes the most resources in the software development and deployment process. It represents all the individual programs and services required to develop, compile, test, secure, stage and deploy code changes. Examples of elements in this layer include desktop systems, shared development servers, script processors, editing environments, static safety checkers (Apex PMD), security checkers, external API endpoints, vendor solutions, and platform CLIs. The platforms may be any combination of Salesforce, VMware, AWS, GCP and Azure and private data centers.
- Orchestration, CI/CD and Observability Tools – This is where the SDLC magic happens. It is like how the conductor of an orchestra commands the actions of their symphony. Inbound messages trigger automated processes involving the repositories, platforms, services, and tools. Observability refers to application instrumentation, logging, error tracing, and performance monitoring. ELK, Prometheus and Splunk are examples of observability projects. Orchestration generally allocates resources for use by a container. Examples of orchestration software include Redhat/OpenShift and Google/Kubernetes. Jenkins, TeamCity, and CircleCI are the leading Continuous Integration and Continuous Delivery (CI/CD) platforms.
- Devops Engineering – This is the key knowledge and actor layer. To efficiently operate the Orchestration, CI/CD and Observability layer engineers who are experienced in performing these tasks in open-source and Salesforce environments are required.
- Application Management Lifecycle – This layer performs the stakeholder’s governance and engineering management of the entire software development process. Common AML strategies used include Waterfall, Agile and Scrum. Notably, the most common AML tool is Jira/Confluence. Simpler project management tools, such as GitHub Projects and Issues, may suffice for some projects.
- Project Stakeholders and Engineering Management – The top layer represents all the actors and stakeholders in the enterprise who need the software project to work.
Building a Salesforce SLDC Solution
Now for the interesting part. How does one construct an SDLC pipeline? That is a question with a thousand possible answers. Allow me to simplify it by taking a high-level look at how all the pieces could be networked together.
Here is a sample solution. Using maximum security precautions, all the project development resources are hosted within the enterprise security perimeter. All public-facing production services are hosted by Salesforce or a public cloud.
An Internet Gateway governs traffic between the enterprise network, the Internet, Salesforce, and the public clouds. Deployment artifacts will include Salesforce change sets and Docker containers.
Let us examine the remaining parts one-by-one:
- Enterprise Data Center – The enterprise data center must offer ephemeral compute resources to devops engineering and host any access points into legacy systems.
- Developer Work Environment – Modern developer workstations are built around Microsoft Visual Studio Code (VS Code). Working on Salesforce or the public clouds also requires installing and configuring various command line interfaces (CLIs), leading to complicated workstation setups. One way to solve this problem to use VS Code Remote SSH or Containers. This enables developers to use a pre-configured and powerful backend service to augment their work.
- Enterprise Devops Resources – Devops services may be purchased as SaaS services on the Internet or hosted internally using secure enterprise resources.
- Source Code & Release Management Repository – If you choose to not use public GitHub for your source code repository and code release management there are many choices for self-hosted options, including GitHub Enterprise.
- Deployment Artifact Server – This is your private Docker repository. For Salesforce managing deployment artifacts is trickier and falls into the realm of metadata backup and management. Private Docker repository services are available on AWS, GCP and Azure.
- Command Server – This is the server that hosts your CI/CD command and control processes. In the course of its duties, the command server directs other devops servers, Salesforce, or the public clouds to initiate actions. For example, the command server receives a message from the source code repository that a new commit has occurred. Next the CI/CD system allocates compute resources for a runner process, which in turn runs scripts to test, compile, build and save a new deployment artifact. That artifact is ultimately deployed to Salesforce or the public clouds by the control server. A SaaS product that performs the control server function is TeamCity from JetBrains.
- Observability Server – Devops engineering depends on knowing what is going on in the networked systems, and to have a good alerting system in place when things go wrong. Observability is well-developed skill in traditional devops, using open-source tools like the ELK stack or Prometheus.
- AML Server – The resources used to implement project management and application lifecycle management software, such as Jira/Confluent.
The Devops Journey Continues
I hope you found some Salesforce SDLC insights in my stack-diagram and networking approach to analyzing the software delivery lifecycle. There is plenty more to explain, so please stay tuned. If you have any comments on improvements on my SDLC nomenclature, I would love to hear from you!
Looking for more Salesforce Devops articles? Check out Salesforce Devops in Early 2021.