Let's set some context
We understand that on premise applications are mentioned as monoliths these days, and basic ALM cycle steps of [Design--> Development-->Build-->Deploy-->Release] though are same, but the frameworks & tools are very different with the ubiquitous advent of Agile, DevOps, Cloud & Mobile.
We also understand that no one likes to wait, automation is important for innovation, so DevOps is umbrella term that streamlines build & deploy phase with version controls like Git, Build frameworks like Maven & CI/CD tools like Jenkins, Artifactory, Ansible etc.
Let's shift gear by going into specific of DevOps in Salesforce ecosystem where it is all about Sandboxes & Orgs. Usually developers will work on their changes in Developer Sandbox, and use change sets, Ant Migration Tool to push their changes on other Sandboxes for Integration Testing, UAT & Production Releases. In this Org Based Approach of releases with multiple Change Sets ,Production environments becomes the source of truth after the release cycle & it gets quite cumbersome & error-prone to re-sync the production changes as developers have already began their next release.
With new Salesforce DX tools & Source Based Approach, Salesforce has pushed for practical DevOps and pushing their customers to integrate their Salesforce Orgs with version control & CI/CD tools. Professional Players like Gearset, Flosum, AutoRabit are further refining this approach by creating & implementing solutions using DX Tooling, Metadata API to further enhance customer experience.
Let's talk some Salesforce DX
Monolith developers are quite familiar with deployment build scripts languages like Ant, Maven and enterprise application teams develop the build process with these tools to enable CI/CD. Salesforce DX, based on Source Based Development, streamlines continuous development on lightning platform. Salesforce DX is based on 4 core tenets:
- Team Collaboration: As developers work on features, release engineers have to validate collaborated build for release, and DX tooling along with version control provides consistency to the build process.
- Open Prescriptive: DX prescribes source driven development but keep it quite open by allowing you to choose different VCS (Git, SVN) , Build frameworks (Jenkins, Travis).
- Automated Delivery: It takes quite a bit of automation between feature development & release, and it is quite important to release often in an iterative cycle, so DX supports organizing artifacts in a package.
- Build for Enterprise: DX helps developers create ephemeral orgs, and tooling has to support many enterprises by creating & destroying scratch orgs, package monitoring, so DX is designed to meet the scale of enterprise ecosystem.
DX is providing tools like SFDX CLI, Scratch Orgs, Unlocked Packages, IDEs & Text Editors with Plugins along with Sandboxes, Change Set approaches to enable Agile Delivery.
Salesforce DX Tooling
As developers we have to agree that a bit of design should always precede a development phase, and teams take different approaches of white boarding, design specs, prototyping and many other. A bit of design enables modularity & developers start spitting artifacts by creating projects. It is very important that developers working in an ecosystem / framework gets the same base structure to ensure consistency and with DX, and you can do that by using a CLI command [sfdx force:project:create -n geolocation].
Salesforce is Metadata Aware, which helps auto generate freebies but can spit out big files & a bit problematic from change management perspective. With DX, you still control how you break up the customizations but developers can use scratch orgs as their development environment which easily syncs with other programmatic artifacts of the project.
- Salesforce DX Project: It contains local copy of related artifacts, app code or customization, and core assets required to synchronize source & metadata with the scratch orgs.
- Scratch Orgs: It is a dedicated & configurable salesforce environments but are designed to be short lived and re-created based on project configuration.
- Salesforce Command Line Interface: Developers with Heroku skills are quite used to CLI interface and SFDC CLI has combined capabilities from several APIs like Metadata API, Tooling API & provides a command interface to support build scripting functions.
- Salesforce Extensions for VS Code: With DX tooling, Salesforce has provided plugins for VS code, with which developers get an Integrated Development Environment to develop on Lightning Platform.
Deploy with Unlocked Packages
While working as middleware consultant, I am quite used to deployment artifacts build as Jars which are pushed to servers in upstream environments like UAT, Production. In Salesforce ecosystem, we are working with metadata, and by definition packages are container that help you organize & deploy your metadata. Some of the advantages of packaging based development:
a) Packages allow you to iterate with versions by taking the snapshot of metadata tracked by a unique VersionID, and at any give time you can map the deployed artifacts to the installed version.
b) Unlocked packages specifically keep the design quite flexible by allowing you to add, update metadata even directly in Production environment, but it make sense to sync those changes back into Dev branch.
Comparing ChangeSets & Package Based Deployment
With ChangeSet, Org changes are moved between Sandboxes until they are pushed to production, but with Packages, code exist in version control & tested in Scratch Orgs until Dev complete stage, which is when they are packaged as a deployable artifact into upstream release environments.
Links & Reference
a) https://trailhead.salesforce.com/trails/sfdx_get_started
No comments:
Post a Comment