In 2012, Joel Spolsky wrote a prescient and powerful post about Software Inventory. He encouraged software development teams to look at the software development process like a factory would look at their production process. Physical factories carry excess inventory in order to prevent downtime and the negative consequences that occur if you run out of any of your key supplies. Idle time is a bad thing for the factory and that’s why they carry some extra inventory - so that no one step of the process becomes a bottleneck for the rest. Software teams can easily empathize with taking extra precaution to limit downtime.
But Spolsky notes that there is also a cost associated with having too much inventory. Companies like Toyota have gone to great lengths to ensure that they have just the right amount of inventory and no more. Having too much inventory is problematic because it ties up resources in an unproductive way. If you have $100,000 in inventory, that’s $100,000 not being spent on something useful. (Interestingly, many companies actually use Salesforce and the Force.com to manage their inventory!)
As Spolsky puts it:
The “cost” of code inventory is huge. It might add up to six or twelve months of work that is stuck in the assembly line and not yet in customers’ hands. This could be the difference between having a cutting-edge product (iPhone) or constantly playing catchup (Windows Phone).
Don’t let completed features pile up in ways that don’t make you money. Work on your deployment process so that you can get customers features in months rather than years. If you’re already shipping monthly, figure out how to ship weekly. Keep pushing the bar on more and more frequent deployment of smaller and smaller changes.
Quality and Speed
Getting inventory out the door quickly is a competitive advantage for teams. Features that pile up and remain undeployed are expensive just as too much inventory is expensive. However, there is a competing interest that every release manager is well aware of: quality. You want to avoid having too much inventory piling up, but you also want to assure that your product is high quality. You can’t simply sacrifice quality in the name of speed. Launching fast is a competitive advantage but bug ridden software is not. This is a visceral pain that most software teams feel acutely. Anyone who’s ever released a semi-major bug knows that you will hear from your users loud and clear if things aren’t working as expected.
Managing both of these interests is the art of release management. Any release manager has to deal with this. But it’s especially acute in the Salesforce ecosystem where there is a wide variety of stakeholders who can be involved in development and release management: admins, developers, architects, business analysts, product managers, etc.
So what are the options for a Salesforce release manager?
Coding in Production
Quality: Very low Speed: Fast in the short term
At this point, we don’t really need to convince you why this is not a good idea, right?
Speed: Low Quality: Low
Change sets are the out of the box release management option from Salesforce. They allow you to migrate code and configuration changes from one Salesforce sandbox to the next using a graphical user interface provided by Salesforce.
Change sets are convenient because they come out of the box from Salesforce. You don’t have to set up anything custom and you don’t plan to do maintenance on custom scripts. You can be fairly confident that change sets will continue to work as new Salesforce release come out.
But unfortunately change sets score fairly low on both our speed and quality metrics.
Change sets are slow because they require a lot of manual hand holding. You have to manually keep track of everything that has changed in a given release. (We see a lot of teams using spreadsheets to do this.) This is time consuming and ineffective because it is so easy to forget to log all changes. Furthermore, there is a pretty complex dependency tree in any given Salesforce deployment. Change sets provide some functionality here but it’s not always fully accurate. So deployments do not always go through smoothly and can take several attempts. Finally, it’s slow because it requires so much clicking. There is not an automated way with change sets to simply say “Tell me everything that is different between my developer org and the UAT environment I want to deploy to.” Automating this alone would help speed things up significantly.
But change sets also suffer on the quality scorecard. Manual process are prone to human error key dependencies are often missed and the deployment causes unexpected issues. Furthermore, change sets provide no concept of versioning or source control. This makes rollback difficult. It also makes collaboration problematic. Without source control there is no way to ensure certain developers or admins are not overwriting the code of another.
Speed: Moderate Quality: Moderate
The Force.com migration tool, also colloquially known as, “ant scripts” is another option that many release managers turn to. The Force.com migration tool is based on Java/Ant and can be run from the command line. It allows Salesforce developers interact with the Salesforce metadata API to deploy changes. It’s a great tool.
The nice thing about Ant scripts is that they allow for far more automation than change sets. They even allow you to get closer to continuous integration for Salesforce because of this degree of automation.
The biggest challenge with Ant scripts is that they are still not as fast as possible because they are based on Java and highly reliant on querying the Salesforce APIs which are not always performant for large orgs. It’s also challenging to do differential deployments which only write the changes that are actually new.
The Force.com migration tool workflow tends to promote higher quality releases because it presumes that you use some kind of source control tool for version management. Ant scripts also automate more for you and remove the possibility of human error. However, they still require quite a bit maintenance as new API versions and releases come out. So you may find that the automation is less reliable than you might initially hope for.
The other big question for release managers is how to train your entire team to use your release workflow with the Force.com migration tool. What is the best way to ensure your entire team follows the process and does not deviate? For example if an admin goes rogue and makes a quick change directly in an org, this can break your release pipeline. So you have to think about this when accounting for quality.
Speed: High Quality: High
Okay we’re obviously biased, but hear us out. Blue Canvas is designed to optimize the speed and quality trade off for Salesforce release managers. Because Blue Canvas is based on Git at it’s core, there are a number of advantages. The first is speed. Git is written in C and is therefore very fast. Blue Canvas can also minimize the amount of times we need to go directly to the Salesforce APIs which speeds up your release process further. Finally, deployments with Git are incremental so we can deploy only the changes that are different in each given deployment. This is an improvement over Ant scripts which require you to reupload everything.
Blue Canvas also scores well on quality because it keeps things highly automated. Blue Canvas automatically tracks everything that changes on your org. You can quickly query and see what has changed or compare the differences between environments. You aren’t relying on training your team to use a new process. Also, because Blue Canvas is Git based, source control is automatically built into your release management pipeline. This gives you continuous backups and safe merge conflict resolution. If you ever need to rollback you can. And you don’t need to worry about about developers or admins overwriting each other’s work without recourse. Everything is backed up in Git automatically.
To learn more about Blue Canvas, sign up for a free trial today.