Suggestions for how to use RG Source Control in our development path

sam_alexander

We have these paths/systems from Dev to Prod:

Development - Just a sandbox to test and try out code changes before introducing them into the official development path
Code Introduced - Dev Testing
Deployment 1 - Business Analyst Testing
Deployment 2 - UAT
Deployment 2 - Stage for Production (regression and integration testing)
Deployment 3 - Production

Development is a playground and hot mess, so we don't start putting code into the flow to Prod until Dev Testing. We do some basic testing to verify it works as expected then it's deployed up for "Business Analyst Testing".  Our BA's do their stuff and verify it matches the business requirements.  Next deployment goes to two system - one is for UAT where end users can test and the other is for Regression and Integration testing where I test our SSIS processes with a full dataset and verify new code doesn't brake existing code.  It may live here for a period of time depending on the change.

Once UAT and Integration/Regression testing is successful we move it to Production.

Currently I do all this manually, but I would like to work Source Control into it so I can migrate this either automatically or even on a schedule where changes go into TFS and we have accountability of who is making changes and when.  

With all this I'm unsure if we should use one Git repository for our code or one per deployment region.  Also should these be dedicated or shared?  I just don't want the code to be committed to TFS until right before it moves into Prod in-case we need to roll back, but I'd like any feedback on how others do this.

Thanks --

AlexYates

There's a lot to unpack here. I'm going to try to avoid prescribing a process. Instead, here are some principles to think about:

- Use git. But I think you know that already. You need the superior branching that comes with a DVCS.

- Development, for the best part, happens on local DBs and goes into source control BEFORE it gets deployed to any shared environment. Work for different tasks that may need to be deployed independently should be committed to separate source control branches and merged with master when ready to be deployed.

-  When source code is deployed to a shared environment, you take the ENTIRE BRANCH - you don't cherry pick. Your mental model should be based on developing and testing complete versions of code, to avoid wild west environments and "it works on my machine" problems.

- You should avoid multiple long-lived branches, this creates awful merge pain.

- You can generally make your life a lot easier by reducing concurrent pieces of work. One good way to do this is to think about Value Stream Mapping and focussing on reducing wait times throughout the process, and prioritising finishing (deploying to prod) current work over starting new work.

-  Your source control strategy should mirror the reality of how you manage work, otherwise people won't be able to use it effectively.

- Adhering to these principles are more important than maintaining your existing processes.

I advise you read The DevOps Handbook. If you still want to talk this through, get in touch. I'm not sure a forum post will be enough to help you solve your underlying issues.