Continuous delivery landscape for Salesforce Applications -1
Release management automation of Salesforce applications have different challenges compared to the J2EE / Dot Net worlds . Theortically , the release life cycle on Force.com development platform may follow the same release path of Development –> QA –> UAT –> Pre-Prod and Production – but the dynamics in the release cycle are different .
Continuous Delivery of Salesforce applications needs the following challenges [ if not limited to ] to be addressed in the CI infrastructure .
1. Cloud driven design : Salesforce is a cloud platform for rapidly developing applications . CI tools must be designed on how to package, deploy and test in cloud . Essentially, when the development platform is in cloud – there is every possibility that the deployment and test infrastructure is expected to be in the cloud as well .
Hence, Continuous Delivery system needs to have support for the on-premise installation as well as on-demand / hosted support .
2. Automated packaging and deployments
Salesforce development platform has some release management goals , some limitations in the process and would look at Continuous Integration tool to fill those gaps rather than a system for which continuous integration is all about compiling some java code or deploying a war file into an application server with a bunch of bash scripts that have been lying for years now .
For instance – take the case of uninstallation
An uninstall of an application or package in a developer org is not like deleting the app from a webapps folder in a tomcat installation. Though Salesforce migration guide suggest that the package.xml can be renamed to destructivechanges.xml and run to uninstall an application – the reality sees lot of pain points around it.
The package.xml can have wild card support some of its metadata members , but the destructive changes will not work – if there are wild cards in the package. So, there should be an effort to update the package.xml substituting the wild cards with proper values being filled with additional API call and then one should attempt un-installation.
Hey, wait !! if you think uninstallation can be done – you may not just lucky yet since if the objects / fields in the application has circular references – they cannot be deleted unless the chain is broken.
This is just tip of the iceberg where a traditional CI tool , just raises its hands and say -” I am world’s most generic CI tool and hence you need to take care of these minute level details . Give me ant / batch file and I will run it for you , but please don’t ask me all these questions” .
3. Data Migration
Salesforce platform hosts the code as well as data and hence setting test data and creating full operational Organization / Sandbox in automated manner needs the support of an built-in Salesforce data loader attached to the CI Infrastructure . A holistic release management system will facilitate both code deployment and data migration as part of the tooling design . Apart from AutoRABIT , no CI tool can even claim this support .
4. Version Control Support
Salesforce development teams with mix of business users and developers were always reluctant to move onto a external version control tool like Subversion or GIT or TFS , but there is a visible growth of teams favoring a version control system considering its additional benefits of snapshot storage , audit etc., . However, teams who are in early adoption stage would ideally like to see a tool that can do “auto-commit” to a version control system after the build which is in-contrast to most CI tools today – where they are designed to fetch the latest changes from a version control tool to start the build process . May not be the ideal design goal of a CI tool of yesterday , but very relavant today .
More to be continued …
In the next blog – we will us discuss about the requirements of a powerful Continous delivery system for Salesforce applications that inspired AutoRABIT to what it is today ….