A DTAP Street is a well-known method in IT to launch properly tested and approved software. First develop in a separate environment , transferring to testing, then accept for the acceptance test by the end users and finally to production. In the cloud era , this method seems to have an inhibitory effect on the rate of release of new functionalities.
DTAP in the Cloud
Major suppliers of cloud software, such as Google and Salesforce, launched at the assembly line of new functionalities, sometimes monthly or even weekly. Google last year but released 20,000 new functionalities. Continuous delivery at its best, but more about that in a future blog. It should be clear that this makes different demands on the steps Develop-Acceptance Test-production. Itself we run here a bit in daily practice with Force.com against it. The main challenges are:
Constantly uploading and downloading to the Cloud
Usually develops Salesforce software developer in the Salesforce Cloud. For the purposes of DTAP he needs to upload and download the software between the different environments. When Force.com is especially downloading a problem, as well as version control. And that is definitely an (accelerated) DTAP obviously indispensable.
Security requirements for testing by PaaS provider.
When creating a managed package ‘in Salesforce that you want to place in the Appexchange (say the App Store Salesforce), you encounter a mandatory and especially time-consuming and complicated security process.
Requirements for the ‘packaging’ of functionality PaaS provider.
When creating a managed package ‘is also the mandatory namespace into play. With this prefix in the software Salesforce can separate the code from other managed packages. This prefix is added only in the DTAP normally at the step A to P. Again, exists no standard functionality in Salesforce.
Deployment packages into the production environment.
Also for deploying packages is no standard functionality available. Furthermore, you need to meet in the performance of the production step to certain quality requirements, such as having sufficient test code coverage (the number of lines of software that is covered by tests).
Without going into too much detail here and going into the technique used, we as Case Nine those wrinkles smoothed as much as possible by using tools such as TeamCity and own scripts. We do this as it were, a PaaS given to Salesforce. And now we hope that within Salesforce plays him. May the Force be with us! We will keep you informed.