Strategy to setup Subversion for Salesforce development for Agile Team
Download as PPTX, PDF0 likes1,960 views
The document outlines the setup and processes for using Subversion (SVN) for Salesforce in agile teams, detailing strategies for regular sprints, emergency releases, independent feature releases, and urgent weekly fixes. It emphasizes the importance of branch naming conventions, code checking out, committing changes, and notifying the release team for production releases. Additionally, it provides a list of components that should be managed in Subversion, along with their descriptions.
Strategy to setup Subversion for Salesforce development for Agile Team
- 1. Setting up Subversion for Salesforce For Agile Teams • Process. • Setup • Components • Work. 1
- 2. Svn Process: Regular Sprints SVN Strategy for Regular Sprints. 2
- 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
- 4. Svn Process: Emergency Release 4
- 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
- 6. Svn Process: Features with independent releases 6
- 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
- 8. Svn Process: Urgent /weekly fixes 8
- 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