Blog
Contact UsWhether you have been working with Salesforce.com for years or just considering a new implementation, this is some information you can really use.
Salesforce.com has helped to define cloud-based computing and has revolutionized the industry with an intuitive, secure, flexible, configurable, and scalable platform that has allowed businesses of all sizes to solve their business problems without all of the infrastructure headaches of traditional IT projects. Those of us that have a long history with the product know how dramatically different this technology is from the status quo and we believe in the benefits that can be realized.
With all of that said, the platform is evolving to support the needs of large, more complex organizations. What does this really mean? It means that there are more choices, more technology, and more capability that ever before. With all of these capabilities and choices comes some responsibility to get educated on how to manage change so that it is reliable and predictable.
I have used this forum to post a number of articles about the people-focused aspects of change. In this post, I want to address some of the more technical matters that are often overlooked within the context of salesforce.com implementations, and that is the topic of Environment Management.
Environment Management Defined
My high school history teacher used to parrot the phase “words mean things” when challenging abstract arguments. For this reason, I want to be clear about the context that I am using to define “Environment Management.” Simply put, Environment Management is the strategy, process and tools used to manage a Salesforce.com instance (metadata) so that it remains current. This includes the management of multiple environments (development, QA, staging, training, production, etc) such that the correct updates are deployed to the correct environment at the correct time.
A History Lesson
In the client server world, environment management and deployment were largely coordinated with the use of source control tools and defined release cycles between environments. With a combination of process and technology, new “builds” were deployed from one environment to another to protect the production environment while creating a rollback path. With compiled projects, we could be assured that the application in one environment would be identically synchronized with that in another environment because everything was packaged together.
For web applications, the same was generally true. Although the elements of a web application were a bit more dispersed, each component (web form, class, controller, etc) could be managed within source control and differences could be easily assessed.
The early days of salesforce.com removed this complexity by providing a single, real time environment for applications. Any updates made through declarative development (e.g. configuration of metadata) were immediately deployed so that all users could take advantage of the new updates in real time. No more complex IT processes, no more exorbitant lead times… just a world of fast-paced productivity.
As the platform evolved, so did the need to test. The feature set was enhanced such that there were legitimate reasons to leverage a test environment to QA new functionality before it went live in production. There were workflow rules, custom code, approval processes, options that once enabled could not be disabled…. The Sandbox environment was born. The sandbox could be used to try out new features before they were enabled in production, allow users to test or train in an environment separate from the production environment, and could even be refreshed to create an almost-exact replica of production. However, for a long time, it was not possible to promote configurations in the other direction (from Sandbox to Production).
The world has changed again. The use of a sandbox is a requirement for Apex and Visual Force development, and the meta-data API makes it possible to package metadata components through Eclipse, the Force.com migration tool, salesforce.com deployment utility, or through a third party solution like Snapshot.
The Issue
Seemingly, the development of all of this new capability would provide salesforce.com even more validity in the enterprise space, and we could refer back to what we have learned about packaging solutions, deployment, change control and release schedules. This is all true to some extent, but there are nuances of operating in this metadata driven environment that are unique, and without paying close attention to the details there is significant risk in oversimplifying the process.
There is no single silver-bullet solution to perform comprehensive environment deployment in force.com. All of the automation utilities and packages leverage the Metadata API that handles some, but not all, of the components that make up a full environment configuration. This means that no matter which strategy you choose, there will be some manual configuration required in the production environment. The complete list of what is covered and what is not covered through the metadata API is beyond the scope of this article, but examples of those thing include are:
- Apex classes
- Apex triggers
- Analytic snapshots
- Custom applications
- Custom objects
- Custom fields
- Reports/Dashboards
- Custom page Web links
- Custom sites
- Custom tabs
- Etc.
This list of items not covered is extensive, but notable examples include
- Role Hierarchies
- Public Groups
- Approval Processes
- Assignment Rules
- Org Wide Defaults
- Escalation Rules
- Assignment Rules
- Etc.
Solution
The first big step to solving this issue of lacking a comprehensive deployment capability is being aware of the issue. To take you the rest of the way, I recommend a combination of planning and best practice guidelines to ensure success.
Have a Strategy
When it comes to setting up your Salesforce.com environment, it is important to do so with deliberate planning. If your environment requires one or more sandbox environments, be clear about the purpose of each and the promotion path between them. Do you need a separate environment for development, QA, Training, Staging, etc? If so, who will be responsible for maintaining each? What will be the path between them? How often will they be refreshed from production?
Once the environment is established, it will be necessary to determine what means will be used to promote new releases between environments. Will this be an entirely manual process or will a utility be used? If automation is part of the equation, which tool will you select?
Change Control
The need to coordinate manual changes along side automated deployments requires that a strict change control process be implemented. As part of the process, a few guiding principles are helpful:
- Define all dependencies between packaged components or your deployments will fail.
- Make all changes in the development environment (or whichever environment defines the “beginning” of the process). Do not make changes at intermittent stages as they will be much more difficult to track
- Follow a regular cadence of release “trains” for predictable, packaged releases. Do not introduce “hot fixes” as they will also create synchronization issues with other environments.
- Create a backup of the metadata configuration before pushing to production
- Document all changes made to the production environment
- Establish a central point for creating new production changes. This should not be a distributed responsibility.
Select a Tool
If automation is part of the strategy, select a tool that best meetings the needs of your developers/administrators. There are a number of options including the deployment utilities that are packaged into the salesforce.com application, but be selective and understand the feature sets and use model of each.
For more information on environment management, please contact me at bkalma@modelmetrics.com.
Tags: change management, deployment, environment management, force.com deployment, metadata promotion, salesforce.com, snapshot
