As I continue along the journey to CTA, I’ve been preparing to take the Development Life Cycle and Deployment certification exam. This exam covers a range of methodologies, tools, and best practices for managing the cycle of building and deploying new features on the Salesforce platform. It’s an important area of knowledge for any architect working with large teams and/or complex projects and implementations to ensure that new development doesn’t break existing functionality, without sacrificing the ease of declarative modifications that administrators sometimes just implement in production. Like several of the other certifications that comprise the System Architect domain, while this certification does center Salesforce tools, it requires a knowledge of best practices and methodologies that are more broadly applicable in other systems and technology implementations as well.
In my role as a solutions architect up until this point, I haven’t had to put much thought into dev ops— sure, I know to build in a sandbox and then deploy to production using change sets, the metadata api, or SalesforceDX— but having a deeper strategy around environment management hadn’t been necessary with the small teams I’d been working with. Or, so I thought. Then, one day, someone mistakenly refreshed a sandbox that had months worth of work in it that had been planned to deploy to production in the next week— and all of a sudden, having an environment management strategy even for a seemingly small project became critical.
What is Environment Management?
Environment management is the plan and strategy for where your new application or features are built and tested before they are deployed to production. An environment management strategy could be very simple, with changes only occurring in production and their release being managed with profiles and permission sets, or it can be complex, incorporating numerous sandboxes, version control, or continuous integration as changes move from initial development through to deployment. Your environment management plan should cover what work happens in what environment, what the process is for promoting changes from one environment to the next, and what the schedule is for refreshing each environment. Taking the time to think through your environment management approach will help ensure that changes don’t unintentionally overwrite someone else’s work or break production functionality.
Environment Management Approaches
Even on what appears to be a small or simple project, you need to have an environment management strategy. Your strategy might just be “this project only requires simple changes that are safe to make in production (reports, dashboards, list views), so a sandbox is not necessary”— but the point is that you need to make that decision with each project, and communicate the plan to anyone else that is engaged in your development process.
If your project involves any amount of automation– be it workflow, process builder, flow, or code, you need to plan on working in a sandbox. Developing your changes in a sandbox and then deploying to production will allow you to test and ensure that your new automation behaves as you intended, without risking the integrity of your production data. Salesforce makes it dangerously easy to make add automation in production via process builder or flow, but resist the temptation: test it in a sandbox first to help ensure that your shiny new feature won’t do anything unexpected when you release it.
If you’re working on a large team, possibly with multiple projects simultaneously in flight, you may require an environment landscape with numerous sandboxes, supporting individuals developers on each project, integrating project contributions into a single environment, and then performing QA and user acceptance testing before changes are ultimately deployed to production. This sophisticated approach to environment and release management can allow for multiple branches and workstreams to be incorporated while maintaining the integrity of the production environment.
If you have multiple team members working on the same project, in the same sandbox, make sure that everyone is on the same page with the sandbox refresh schedule. One approach can be to limit the access most developers and builders on the team have to the production environment and have all sandbox refreshes handled by the environment manager. Of course, this can become cumbersome if different team members are working in different environments and need to refresh at different intervals. A more scalable approach would be to use a version control system like Git, so that your source of truth can live in a repository that is safe from sandbox refreshes, instead of in the metadata of any individual environment. That is now my preferred approach, especially as SalesforceDX makes it easier to pull and push metadata changes between production, sandbox, and scratch orgs.
Doesn’t environment management make things take twice as long?
Some folks are resistant to working within a robust environment management architecture because it can extend the amount of time it takes for changes to be available in production. However, consider that an ounce of prevention is worth a pound of cure, and developing changes in non-production environments is the best strategy to ensure that you don’t break production functionality when adding new features. Building and testing in production might seem like a faster idea— until you see how long it takes you to fix something when one of your production changes doesn’t go according to plan. There are some changes that can safely happen just in production– think reports, dashboards, or list views– without having an impact on your production data— but for changes that impact your business logic, integrations, or architecture, the safest approach is to start in a sandbox. The extra bit of time to manage that deployment process is worth the risk mitigation for your production environment.