Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

Grant will be modifying the talk w/c 1st September to shorten and refocus 50:50 ratio of content on CI and release management Make it clearer that CI is the natural next step on from version control Go into more detail on CI as a process Cut out demo on version control as an entity Reduce rollback and recovery slides to one slide

We’ll also demo a database change from the point of version control all the way through to release to production, so you can see it in practice.

Animated slide shows that people often think continuous deployment is the same as continuous delivery – but this isn’t the case. This is an important distinction for database professionals. Continuous delivery and continuous deployment are very different beasts. Continuous delivery is about always being ready, at any point in time, to release your software. Continuous deployment, on the other hand, is about having such confidence in your automated testing and deployment procedures, that you automatically release a change straight from development into production (via other test servers of course!) without human intervention.

See where continuous delivery fits in on the continuum of a release pipeline – and continuous processes. Important to emphasise the quality check at the approval gate stage for continuous delivery – this is a chance for DBAs to review scripts before they enter the production environment.

From a technology standpoint, before you think about continuous delivery, you need to get your database under control. This is a quick recap of the version control and CI talk in the series – essentially, version control and continuously integrating and reporting back on builds needs to be in place.

Show that it exists in source control. Show the folder so that they can see the create scripts, it’s not a series of changes scripts.

Detailed CI demo. Use TeamCity. Emphasize the generation of the artifact, nuget package.

Introduce octopus. Using artifact. Primarily test and talk about artifact. Works in TFS too through a pretty gui.

Staging should be as close as possible an environment to Production – here are some characteristics to think about. Idea is that you can use Staging/pre-Production to debug and diagnose any issues before a release enters the (locked down) Production environment.

Hold on – you also need to check Production is still in the same state as you expect – what if the database has ‘drifted’ – especially the schema - since you last looked?

Need to be aware of unexpected changes being made to Production – or risk deployment failing, or data loss.

Ok, so we’ve determined there’s been no drift. Are we ready to go? Not quite yet…

Even after all the testing, the review, the checks, we should still obviously plan for things to go wrong. Build out a rollback and recovery strategy – there are several options to consider.

Very basic first step is to have a backup of your Production environment. You probably have these already running regularly!

Pre-prod and the generation of a t-sql script. Also mention drift resistance there.

See where continuous delivery fits in on the continuum of a release pipeline – and continuous processes. Important to emphasise the quality check at the approval gate stage for continuous delivery – this is a chance for DBAs to review scripts before they enter the production environment.

10.
Get your database under control
• Use version control for all code
(including tests)
• Commit early, commit often
• Use tools
o If it’s hard, people don’t do it
• Train people
• Build often
SOURCE
CONTROL