This deck would help IT managers to implement subversion or any code version tool for salesforce crm developments. This deck has
a. Strategy for code control
b. process for deployment
c. components to be part of the code repository
3. Svn Process: Regular Sprints
SVN Team
Create a svn branch with name mmyyyy.
At the end of QA testing, locks the branch and prepares for production release.
Merge the Branch with production trunc for production release.
Notify release team for production release and enable release.
Development Team
Check out code from subversion branch.
Commit and update changes to subversion on a daily basis.
3
5. Svn Process: Emergency Release
SVN Team
Create a svn branch with name emrmmddyyyy.
At the end of QA testing, locks the branch and prepares for production release.
Merges the Branch with production trunc after the production release is done successful.
Notify release team for production release and enable release.
Development Team
Check out code from subversion branch.
Commit and update changes to subversion.
5
7. Svn Process: Features with independent releases
SVN Team
Create a svn branch with name proj_feature.
At the end of QA testing, locks the branch and prepares for production release.
Notify release team for production release and enable release.
Development Team
Check out code from subversion branch.
Commit and update changes to subversion.
Merge the branch with sprintmmdd branch or sprintmmdd_alpha branch during sprint releases.
7
9. Svn Process: Urgent /weekly fixes
SVN Team
Create a svn branch with name urgentmmddyyyy every week except for the final week.
This branch will be locked down on Friday (week 1), so that it can be deployed into production on Wednesday
(week 2 of sprint)
On Monday (week 2 and week 3), the svn team will create urgentmmddyyyy_alpha branch. This alpha branch will
be created from the already existing locked Urgent branch.
Once the latest code from locked urgentmmddyyyy branch is deployed into production, it is merged to prod
branch, a new urgentmmddyyyy branch will be created from the prod branch.
At this time the urgentmmddyyyy_alpha is de-activated and merged to new urgentmmddyyyy branch. Now all the
development will happen on this urgent branch until the time it is locked at the end of the week
Notify svn team for production release and enable release.
Development Team
Check out code from subversion branch.
Commit and update changes to subversion.
9
10. Components:
List of components which should be in subversion
– Configuration components like custom objects, fields, workflows etc. which are modified by point and click should
be stored separately using app exchange tools.
– In the absence of using app exchange products, metadata changes can be stored as xml files in the repository.
– Configuration data like custom settings, custom objects which hold look up data should not be stored in the
repository and should always be referenced from production org.
Component
Description
Apex Classes
These are apex classes used for custom code
Visualforce pages
These are custom visual force pages.
Components
These are reusable visual components used on
visual force pages.
Triggers
Back end database classes
Static resources
These are static files like zip files, pdf and other
files referenced on visual force pages.
Email services
These are email service classes which are used to
parsing emails.
10
11. Work:
Work
Developers would need to checkout there current code from the current sprint branch created by Sprint Zeta team.
End of the day, developers would need to commit there code to the branch.
For the next sprint, developers would need to check out the code from the alpha branch and make changes and
commit to the alpha branch at the end of the day.
11