Updated branching strategy for the NASCAR Digital Media Technical Operations team. Outlines how source code branches are managed and promoted throughout the SDLC for NASCAR.com.

1. BRANCHING
STRATEGY
2.0
AN UPDATED DEVELOPMENT, QUALITY
ASSURANCE AND DEPLOYMENT
WORKFLOW

2. OUR GOALS
BRANCHING STRATEGY 2.0

3. OUR GOALS
• Reduce and/or eliminate the need to revert code
• Reduce the likelihood of deploying incomplete features
• Create more predictable and well-tested Releases
• Ensure that no changes go untested
• Ensure that no changes bypass the SIM process
• Improve stability of the Dev and Beta Environments
• Deliver a better quality product to our business units
• Deliver a better quality product to the end user

4. OVERVIEW
BRANCHING STRATEGY 2.0

5. COMPLETE BRANCH
OVERVIEW

6. OVERVIEW
• Multiple code branches, each targeted at specific
Environments (Dev, Beta and Staging)
• Testing in isolation for each feature and/or change
• Identifies dependencies early on in the process
• Reduces / eliminates code reverts by only promoting
approved code to the next environment
• Reduces environmental instability by ensuring only
approved code is deployed to the next environment
(that’s currently not the case)

7. IN-DEPTH
BRANCHING STRATEGY 2.0

8. MORE ANALYSIS WORK
• Each Sprint begins with a bit more up-front work to ensure
that the branches are properly created
• Developers have more responsibility to migrate their work
each Sprint
• Forces team members to have a better picture of their
work for each Sprint
• Additional QA reviews at the start of a Sprint cycle
• Additional Pull Request / Merge steps means code is
being peer reviewed more frequently and at multiple steps

9. BEGINNING THE SPRINT

10. TUESDAY MORNING
PROCESS

11. SOME THINGS STAY THE
SAME
• Developers still work from Feature Branches
• Work is still completed in finite chunks that can be
independently tested
• QA still does a full review prior to Beta deployment
• UAT testing still happens on Beta
• Tickets are managed in the same way
• JIRA statuses largely stay the same, just one addition

12. DEVELOPMENT
PROCESS

13. QA PROCESS

14. UAT PROCESS

15. SOME THINGS CHANGE
FOR THE BETTER
• Formal Code Freeze at 8:00 AM EST on Mondays
• Beta / UAT Environment will be available for UAT testing
throughout release day
• Multiple, Full Regression Tests on Release Day
• Race Simulation(s) on Release Day
• No Last-Minute work is committed into the Release-
Candidate
• Production-Ready release is available in a NEW Staging
Environment all throughout the Sprint cycle.

16. DAY OF DEPLOYMENT

17. CREATING THE
RELEASE

18. QUESTIONS?
BRANCHING STRATEGY 2.0