If you write code to SQL Server then you might be interested in this: I have written a tSQLt tdd training course which has helped over 500 people learn both tSQLt and how to apply TDD practices to their SQL Server T-SQL development, you can join the course at https://courses.agilesql.club.
This post is for a specific type of person if you are:
- New to source control
- Are getting started on your path to the continuous delivery nirvana
- Have been able to get your database into some sort of source control system
- Have more than one person checking in code to the database source
- You are unsure what yo do next
Then this post is for you!
Choosing a source control system and tools to manage your database code is a great hurdle to have got past, well done!
Actually getting your database into that source control system is another difficult hurdle to get last, double well done!
Now you should be starting to think about the next steps, and the sort of things that are on the horizon is, not immediately but not too far away (1-6 months):
- Generating deployment scripts
- Provisioning test databases to deploy to
- Writing some tests
- Automating the running of those tests
- Using a build server to do all this for you
- Sacking your dba’s (jokes ha ha)
But what about now?
The thing that I would do now is to:
- Determine your branching and release strategy
- Start checking in and merging changes
- Generate/gather deploy scripts
- Nothing else
These things are so important to get right early on. It is hard to choose a correct system until you are where you are now. Until you have chosen a process and started using it, it is hard to know whether it works for you.
Determine your branching and release strategy
How are you going to manage your code while changes are going on? Typically you will want to be able to:
- Check new features into the code repository
- Check-in hotfixes to the current production and not lose those changes when the latest features are checked in
- Allow multiple developers to check code in at the same time
There are a few different approaches, and my favourite is the git approach of creating a branch for each feature then merging back to master when the feature is ready to go to production but this favours getting changes out to production pretty quickly so you may not be ready for this yet.
Have a look at different branching strategies that your source control system uses and decide on one that you and your team can understand and work with.
When you have decided on your branching strategy, stick to it and make sure everyone follows the system. If you have had no source control and suddenly have source control it takes quite a lot of discipline as a development team to ensure you follow the process. Someone will forget to check something in, and someone will skip the process. Keep on eye on check-ins, make sure everyone follows the process - it is a big change in how SQL developers work so understand that this in and of itself is a major change for your team.
Start checking in and merging changes
Checking in code is the next step and having multiple developers means that you will have to start merging each other’s changes. Let the developers check in code and merge their changes, try out different tools for merging changes. If you have TFS, you probably have visual studio which has a decent merge tool built into it. If you are using git look at SourceTree or git Kraken.
You will get problems when you merge your changes, do the first few merges together and see where doing things like reformatting long stored procedures causes extra changes that are more challenging to deal with when other smaller changes to the procedures are merged.
Generate/gather deploy scripts
The next thing you will want to do is start to see some value from all this work, and I’m not suggesting that you start pushing all your changes to production yet (you haven’t even any tests yet!). Whatever type of tool you change chosen (automatically generate scripts/manage migration scripts etc.) find a way to generate those or gather them together, so you no longer have to spend x hours every release “gathering the scripts”. This starts to show value and has the benefit that people can’t bypass the source control system easily.
I don’t mean actually nothing, get on and do some actual work (you lazy little…)! What I mean is nothing more on your ci/cd process for now. You have a good 1-3 months work to do to perfect what you have, to work and get this bit nailed :)