This week was all about release management with Salesforce.com. We had people in town from all over the globe and conferences with our Salesforce.com reps to determine the most manageable and efficient way to release code into Production.
After four days of meetings our main conclusion is that release management with Salesforce.com is neither a science nor an art. It's a chore. Developers coming from a Windows or Java development backgrounds will probably need some time to work their way into this "process". The release management process is painful, but to Salesforce.com's credit it is getting better with each API release.
Some of our main finding include the following:
Develop a Process
With a global team, developing a release management methodology is essential. You need to define roles and responsibilities early on. This process may be uncomfortable at times when you have to make code changes in multiple sandboxes or update standard picklist values in Dev, Test and UAT, but without these processes being strictly adhered to, you'll have out of sync sandboxes with inconsistent functionality. This is not to say that your processes will not evolve. They absolutely must and will evolve as you determine best practices due to experience and API updates.
Large and Complex Environment
Salesforce.com has some good documentation on the release management process which will probably work well for most small to medium sized organization. However, we have a global Saleforce.com project team with multiple projects running concurrently in all continents. We have 15 development sandboxes, 5 test sandboxes, 1 UAT sandbox and 1 Production box. Our production Org consists of 40+ distinct and separately functioning companies. Therefore releasing code into Production that breaks something will have a disastrous impact. The processes that Salesforce.com outlines simply will not accommodate our needs. We had to develop our own methodology for refreshing sandboxes, migrating code, communication changes, testing, etc..
Weak Metadata API
Don't get me wrong... I love the metadata API for what it can do. I'm not sure how we lived without it before. With that said, it is still severely lacking in functionality (deploying standard picklist values, pushing field level security, etc). The Metadata API is also confusing as there are multiple, disparate ways to work with it:
- CRUD-Based Metadata Development (Programmable) - Use the CRUD-based metadata calls to create, update, or delete setup and configuration components for your organization or application. These configuration components include custom objects, custom fields, and other configuration metadata. The metadata calls mimic the behavior in the Salesforce user interface for creating, updating, or deleting components.
- Declarative Metadata Development (XML-based) - Use the file-based metadata API deploy() and retrieve() calls to facilitate Salesforce application development and deployment. You can create text files that define components, such as custom objects, custom fields, s-controls, Apex code packages, and other Salesforce objects, and then deploy these artifacts to a Salesforce organization.
Minimize Changes to Production
One of our main issues with Salesforce.com is the lack of an effective audit trail for the way our company operates. For example, we not able to effectively track who added a picklist value for which project or who changed field level security for a specific recordtype. To minimize the risk of a developer, BA or project manager making a mistake in Production, we hired a Release Manager who's sole responsibility is to manage the Production Org. There are now relatively few users that have SysAdmin rights in production and the Release Manager is the only user that can deploy code into Production or make configuration changes. A detailed migration log provided by the project manager assists him in the process.
Release Management Tools
The lack of release management tools is frustrating. Salesforce.com will argue that you can deploy with Eclipse and/or ANT but their functionality is limited to the API. We tried DreamFactory's Snapshot but had limited success. It was very good at viewing and making changes to objects across different orgs but the configuration changes were weak at best. We received a number of conflicting status messages and false responses to pushes. In DreamFactory's defense, their software is limited to the Salesforce.com's API so they can only do so much. We debated adopting Snapshot but the yearly price was simply too high what it can actually do. In the end we decied to stick with Eclipse and ANT for automated deployments.
If anyone has any insight on release management I would love to hear them. Honestly.
