DevOps commonly refers to the combination of development and operations processes, methodologies and tools in order to streamline software development. DevOps helps companies deliver and improve applications faster, enabling their businesses to better service customers. So naturally, as companies continue their digital transformation journeys, DevOps is a great fit, right?
Salesforce is an extremely powerful platform because it enables admins to configure updates rather than custom coding new features. This is great for accelerating the production of new features, but as Salesforce is leveraged for more complex transformation projects, companies are building customizations that require more code and deeper testing—and the need DevOps.
Scaling DevOps across teams of developers and admins can be really difficult. That’s because DevOps tools and methods are rooted in command line, version control, testing scripts and other development techniques that admins typically don’t learn. But as the need for DevOps grows, it’s time for admins to get involved with DevOps.
And the first step is to familiarize yourself with the terms and tools that you’ll encounter in your DevOps journey. Get started with the Admin’s Quick Glossary to Understanding Salesforce DevOps.
Incremental delivery, team collaboration, and continual learning are the key characteristics of the agile approach to software development. Agile focuses on creating a minimum viable product (MVP) and improving it through iterations or “sprints.”
Ant, also known as the Force.com migration tool, is a Java/Ant-based command-line utility used to move metadata between a local folder and an org. Developers manage interactions using a command-line interface (CLI). There is no user interface.
Developers deploy sets of metadata changes from one environment to another by building code packages manually. The developer builds the packages and organizes them into a single folder, then deploys the folder using Ant.
Apex is a programming language that allows users to add and interact with data in Salesforce. It extends the core functions provided by the platform by giving more flexibility in customizing functions and logic.
API stands for Application Programming Interface. APIs allow two pieces of software to interact and share information.
Application Lifecycle Management (ALM)
ALM refers to the end-to-end process of designing, developing, testing, deploying, and retiring a software application. It includes ongoing application improvement and support.
Azure DevOps refers to Microsoft's DevOps tools and services. The toolset facilitates agile, includes Git repositories and helps team document requirements and changes.
BitBucket is Atlassian’s Git-based version control system. See version control below for more details.
A branch is an independent working environment in version control systems or source control where developers isolate and test new procedures from other development work during the build.
Developers can work in parallel, review each other’s work, and control change releases for testing.
Change Fail Rate
The change fail rate is the percentage of changes to production or released to users that result in degraded service (e.g., lead to service impairment or service outage) and subsequently require remediation (e.g., need a hotfix, rollback, fix forward, patch).
In IT, change management is the process of controlling the implementation and maintenance of the software infrastructure applications using change controls and processes such as version control (see below) or source control.
Change management is an essential principle of DevOps to keep complex distributed systems moving rapidly through continuous integration and deployment.
Change sets is a point-and-click tool provided by Salesforce that developers use to migrate metadata changes between orgs as well as synchronize metadata between a source org and a target org.
The developer configures two orgs to send and receive changes. The orgs must be linked through a relationship to a shared production space such as a sandbox or developer environment, creating each from the same org.
Developers build change sets by manually selecting components through a user interface in the source org. The developer then deploys and stages the change set in the target orgs, where the changes are applied.
A combination of continuous integration (see below) and continuous development (see below), the term CI/CD is used frequently to represent the relationship between the two concepts.
Continuous development is an extension of continuous integration. CI automates testing, and CD automates deployment. Put together, CI/CD helps DevOps build, test, release, and deploy changes quickly and reliably at a frequency that suits your business needs.
A command line is a text-based user interface, essentially a blank line on the screen allowing the developer to type in instructions or code for execution. Using command line coding requires a skilled developer or user to perform changes. To simplify changes, Salesforce DevOps typically uses Ant (see above) or SFDX (see below), which have more straightforward user interfaces that don't require coding expertise.
Commit is a term used to describe the collections of changes in source code. The developer adds changes to a branch and records the latest stage in the development process.
Version control automatically tracks changes made to the files. Upon completing part of a feature, the developer "commits" the changes and provides a description.
Continuous Delivery (CD)
An extension of continuous integration (see below), DevOps sometimes uses the term interchangeably. CD ensures new changes are released to customers quickly and reliably.
Developers also use CD to automate the release process where they can deploy an application anytime.
Continuous Integration (CI)
CI is a development process for building and testing code automatically each time a developer commits changes to version control.
Developers share code and unit tests using CI to merge changes into a shared version control repository. The commit (see above) triggers an automated build system for pulling the newest code from the shared repository to build, test, and validate a full master branch, trunk, or main.
Deployment Frequency (also known as Deployment Velocity)
Deployment frequency measures the time it takes to develop, test, implement, and deploy changes to an environment such as production. The higher the frequency, the smoother the process occurs because finding issues slows the velocity, a sign of problems in the deployment pipeline's efficiency.
The deployment pipeline is the automated process for making code available to application users. It provides developers a reliable and rapid method of developing, testing, implementing, and deploying code changes to the application.
DevOps refers to the technical and operational aspects of software releases, including packaging, releasing, and monitoring the changes throughout the software development lifecycle. Teams use DevOps practices to release regularly and reliably in shorter release cycles.
Git is the most commonly used type of version control system (VCS), also known as Source Control (see below). It is the foundation and framework used to define change tracking and how users can interact with the system.
Git is a distributed version control system containing a complete copy of the repository and all project files distributed to each developer for project coordination.
Git vendors include GitHub, BitBucket (see above), and GitLab.
A Git repository is the .git/ folder with the Git (see above) version control system). The repository tracks all the changes made to the files of a project. Deleting it deletes all project history.
Integrated Development Environment (IDE)
IDEs provide developers with a comprehensive set of software development tools, rather like a text editor for writing code.
Typically, an IDE consists of a source code editor, build automation tools, and a debugger. For Salesforce, one of the most popular IDEs is Visual Studio Code.
Lead time is the time elapsed between the identification of a requirement and its deployment. It may be thought of as the time between the creation of a user story and the “story” being placed into production.
Mean Time to Recovery
Mean time to recovery (MTTR) is an essential metric for measuring the time a system takes to recover from a failure. The shorter the MTTR, the less downtime users experience during a service outage or system failure.
Merging is a source control process used to integrate changes from one branch to another, including into the master. It usually involves a code review by other developers and is often performed when a feature is ready for user testing.
During a merge, the version control system uses advanced merging algorithms to automatically splice the two versions of files to produce a coherent result. If the merge fails, it results in a “merge conflict,” which a developer must resolve manually.
Metadata is the coding structure of Salesforce. Metadata alteration occurs when a developer makes changes to the platform, such as adding a new custom field.
Metadata controls user access to pages, color schemes, and UI layouts, among other things.
This is another name for a package file or package manifest.
The term is used when retrieving or deploying metadata using Ant or SFGX CLI. The package file defines the metadata request from an org or deploys it to an org.
Pull Request (PR)
A pull request is also known as a merge request. PRs are used in version or source control systems and allow developers to notify team members when a feature is complete.
Once a feature branch is ready, a developer files a pull request to allow the metadata to merge two branches in a single branch automatically. Developers can provide code feedback, test for conflicts, track change history, and control when and where code is merged.
Regression testing is the process of testing software after changes are made to ensure it performs correctly. It can include tests of both the software’s functional and non-functional performance.
Functional testing checks software for correct behavior and result provision. Non-functional testing checks software operation, including speed and the ability to handle high data volumes.
This refers to the DevOps process used for Salesforce. It is a cloud computing service for building, testing, deploying, and managing applications and services through the Salesforce platform.
Salesforce DX (SFDX)
Salesforce DX is an initiative launched by Salesforce to provide modern development tools for Salesforce developers. Tools include packaging, a new CLI, updates to the metadata API, and scratch orgs.
Selenium is a common open-source browser automation tool used frequently in DevOps pipelines. It provides cost benefits to functional testers and test teams that perform UI testing.
In Salesforce, source code refers to metadata representing all Salesforce code or to custom code written within the platform. It’s often used to describe code stored in a version control system (see below), also known as a source control system.
Static Code Analysis (SCA)
SCA reviews code to identify bugs, detect bad practices, and enforce developer adherence to the coding guidelines.
Static code analysis improves team effectiveness by making it easier for developers to review and improve others' code. Rulesets can be modified to suit business needs. SCA ensures a well-written code that follows set standards.
It is often used along with unit testing (see below).
The automation of code testing streamlines the DevOps process. Test automation is essential for Salesforce DevOps to deploy changes, particularly frequent small changes, efficiently. Testing automation also helps DevOps comply with Salesforce code coverage requirements.
Unit testing is a method for automatically testing individual batches of source code to check fit for purpose. It’s generally accepted as a best practice across all software languages and platforms. Developers write unit tests alongside the code to ensure the code works as expected.
Unit tests must be used in Salesforce, a practice enforced by a code coverage rule that states that, before deployment to a production org, developers must check at least 75% of the code.
Version control is also called source control or a version control system. It tracks changes to files.
For Salesforce projects, version control represents the configuration changes as text files and tracks any changes to those text files over time. Typically, text files are created with Apex (see above) or XML (see below).
XML is the language used by Salesforce to write org metadata and custom code.