This is a continuation post to the series of posts on the continuous delivery of Salesforce applications . Incase, if you have missed the first one – please read it here where we discussed about the need for a dedicated CI tool that is sensitive to Salesforce world . In the subsequent posts , we will start discussing the various requirements of Continuous delivery of Salesforce Applications .
Salesforce application development has always had business users part of the development process who prefer working directly with Sandbox / Org rather than using source control for submitting their changes . However, the adoption for source control for Salesforce has always been on the constant rise .
The choice of Version Control System :
Subversion , GIT , TFS etc., all have strong source code management capabilities and has been adopted strongly by Salesforce development teams . While most teams still figure out what is the best version control tool for them – there is no direct answer for the same rather a combination of factors that drive the version control system.
Subversion – has been a preferred choice for development teams for its long existence , active community support , but it needs server installation on the network and is suitable for development teams that are connected on a network .
GIT – is cloud based version control system enabling distributed development , off-line commits with individual repositories and is preferred choice incase of development teams distributed across the globe . GIT also is favoured for its advanced merge capabilities , parallel work streams etc.,
TFS – Team Foundation Server has been used by development teams which have a background of .Net development and it also has strong version control capabilities built into it .
Branching Model for Salesforce Application Development : [ Using GIT ]
Source Control Set Up :
1. Set up a central GIT repository . The default branch in the repository will be master . This master is remote, and every user has to clone this remote It should correspond to the metadata in production. The GIT repository is remote and every user has to clone this once.
2. Set up master branch : After creating central GIT repository , the master branch will be populated with metadata from production. This is done by committing all the metadata folders along with the Package Manifest file to master branch and push to remote repository .
3. Development of new feature : Separate branches can be created for feature development – by creating a branch from master and pushing this branch to central repository.
Every developer part of the development team that is working in this feature will do the following :
a. Create a developer sandbox which is a copy of production , work on his feature either with Apex Code, Visual Force Pages and other components either with Sandbox UI or with Force.com IDE.
b. Developer will fetch the latest metadata components from his Sandbox and sets up Package Manifest file .
a. Clone the central GIT repository. It sets up a local repository pointing to master.
b. Switch to the feature branch.
c. Commit his changes by updating the folders and package file .[ The changes will be committed to his local repository ]
d. Push the changes to remote repository using git push.
Other developers occasionally might use get fetch and git merge , before they push so that they get the changes done by others and resolves any conflicts on the way , before they run their git push command.
4. Testing Phase [ QA, UAT , SIT etc., ]
a. Create a partial Sandbox . [ Only metadata copied from production , no configurations and data ]
b. Deploy the changes from GIT feature branch straight into Sandbox .[ Using AutoRABIT – you can do full automated deployment or selective component based deployment ]
5. Staging and Release
a. Create a full copy sandbox for staging environment . It would be a copy from production along with data and configurations.
b. Deploy the app into Staging environment , run the test cases.
Note : Any fixes found in Steps 4 and Step 5 need to be committed to GIT feature branch in the same manner as Step 3.
6. Production Deployment : Once all the integration, regression , peformance testing is done and fixes are all provided, the application will be deployed into productiom.
At every production deployment – we need to push the changes in the feature branch to master so that master will always correspond to production code.
7. Production Support with any patches or hot fixes :
a. Developers will refresh the changes from production sandbox into their developer sandbox.
b. Create a production support branch from master .
c. Repeat the steps from Step 3 to Step 6.
In the next step, we will talk about the deployment strategies as part of Continuous Delivery of Salesforce Applications .