If you write code to SQL Server then you might be interested in this: at the end of 2017 I wrote a tSQLt tdd training course which has helped over 300 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. The course is free if you are happy to wait 10 weeks to complete it, with 1 lesson being made available per week - if you are in more of a hurry or you would like to help support the project you can purchase the course which makes it instantly available to you.
I saw recently an email where someone stated that the reason that they manually create deployment scripts is that because of the restirctions put on them by the requirements for auditing and the ability to be able to demonstrate exactly what was deployed at what time.
When automating deployments it really makes sense to use a tool to generate the deployment so you can concentrate on writing productive code instead of deployment scripts. How do you balance the ideal of spending less time writing deployments but also ensure you can audit what happened?
If your deployment process looks something like:
- 1. Compare source and destination + Deploy changes
Then you don’t have much chance, but if you split it into two discrete steps:
- 1. Compare source and destination + Create deploy script
- 2. Run deploy script against target
Then this means that you automatically have an audit trail of what was deployed (the deployment script). You also get the added benefit that the deployment script can be manually reviewed and a friendly dba can run it manually or automatically if they have the capabilities.
If you are writing a deployment pipeline for a database and you miss out the continuous delivery step and go straight for continuous deployment then life is actually a little more complicated, especially from an auditing / non-trust of tools point of view.