Press "Enter" to skip to content

Category: Deployment

A Mechanism for Change Management for DBAs

Terri Hurley shares one path:

Back in the day when I received an email from a developer who requested a Production Change, I would copy and paste SQL code from an email to SQL Server to run against a production database. I never bothered to save that code. But later when I was asked for a history of database changes, it was awkward to locate all the previous email requests asking for production changes. Fast forward to present day, most businesses have embraced Change Management Separation of Duties in companies of all sizes.

My preferred path to change management is:

  • All changes go into source control. You can either have the people making changes create the actual scripts to run, or generate them from base changes in source control, dealer’s choice.
  • Each changeset goes to a specific environment when it gets PR’d into the appropriate branch—that is, dev, QA, test, pre-prod, prod, post-prod, next-gen-post-dev-unprod, whatever.
  • DBAs are on pull requests, at least after a certain point. PR to dev? Let the team handle that code review. Once you move nearer to prod, at least one DBA performs a code review.
  • After PR gating happens, your CI/CD system automatically deploys the changes, assuming it passes any continuous integration tests.

This takes time to get right, but it’s very much worth the effort. I worked at a company where they built the release management processes on top of Git + Azure DevOps. You can also use tools like Flyway.

Comments closed

Continuous Deployment in Practice

Bravin Wasike completes a series on continuous integration and continuous deployment:

Continuous Deployment (CD) is an advanced CI/CD practice that takes automation to the next level. It automatically deploys every code change that passes the automated testing phase to production. Unlike Continuous Delivery, which requires manual approval before deploying to production, Continuous Deployment eliminates manual intervention. This allows for seamless and frequent software updates.

Click through for the full article.

Comments closed

Continuous Integration vs Continuous Delivery

Bravin Wasike disambiguates two terms:

Continuous Integration (CI) and Continuous Delivery (CD) are fundamental to DevOps and agile methodologies. They ensure that software is developed, tested, and delivered quickly and efficiently. CI and CD are more than just trending buzzwords. They are crucial processes that help teams deliver quality software at a high velocity. Understanding CI and CD is essential for anyone involved in software development or operations.

In this two-part series, we will demystify continuous integration vs. continuous delivery. In this part 1 article, we will discuss the basic concepts involved in Continuous Integration and Continuous Delivery. The article will highlight primary objectives of CI/CD, their benefits, CI/CD tools examples, key differences between CI and CD and real-world examples of CI/CD.

Read the whole thing. The way I quickly summarize continuous integration, continuous delivery, and continuous deployment is as follows:

  • Continuous integration: you check in code and the build process automatically runs tests to make sure all is well.
  • Continuous delivery: you check in code and, after the continuous integration process automatically runs tests, the continuous delivery process automatically builds the project and makes it available for push-button deployment.
  • Continuous deployment: you check in code and, after the continuous integration process automatically runs tests, the continuous deployment process automatically builds the project and deploys it. No human needs to be involved after check-in if all goes well.
Comments closed

Change Management for the DBA

Terri Hurley moved our cheese:

If you have never been involved in Change Management processes but now find yourself part of one, it may seem a bit overwhelming or confusing. However, the reasons for and benefits of these processes are simple and straightforward.

This article will explain Change Management and how DBAs are involved and can benefit from it.

Read on to learn more about how change management can work for a DBA. I’ve worked for several organizations as they’ve moved from a philosophy of “just do it” toward proper change management, typically for regulatory reasons like Sarbanes-Oxley compliance.

Comments closed

Losing .NET Code with SSIS 2016 Package Deployment

Andy Leonard goes on a quest:

…when one of our earliest SSIS framework customers reached out to share – in the very nicest way possible – that Fail Application on Package Failure in our SSIS framework was “not working.” My response was, “Great Scott!

The customer is running SQL Server 2016. That’s fine for EDNA’s SSIS frameworks because we have framework versions that work with several versions of SSIS and SQL Server from 2012 forward. I maintain a collection of virtual servers built using the tools available for each version, including the operating systems and versions of Visual Studio, SSIS, and SQL Server.

Read on for the context, the story, and what Andy was able to do about it.

Comments closed

Creating Elastic Jobs in TerraForm

Josephine Bush builds a script:

If you aren’t familiar with Terraform and its requisite bits and pieces, I have a post that walks you through them. Let’s hit the ground running. To create Elastic Jobs with Terraform, you need to use the azapi_resource, but before we go down that path, you will use the azurerm resource to create some supporting objects.

Read on for a guide covering requirements and setup.

Comments closed

Target Platform Error Deploying DACPAC to Azure SQL DB

Kunal Rathi troubleshoots an issue:

While deploying a DACPAC project to Azure SQL database using Azure DevOps, you may come across ‘A project which specifies SQL Server 2022 as the target platform cannot be published to Azure SQL Database v12.’ error. In this article, we will see how to fix this issue.

There are plenty of errors in Microsoft products that make little to no sense. This is, by contrast, a rather straightforward one, and Kunal shows how to resolve it.

Comments closed

Database Snapshots for Deployment and Rollback

Andy Brownsword hits upon an underrated feature in SQL Server:

Deploying database changes are relatively easy. Where things get complicated is the rollback. Sure, it’s easy to script out and revert a procedure to a previous version, but what about destructive changes?

In this post we’ll look at how we can use Database Snapshots to remove some of the headache that comes with rolling back changes.

Read on to learn more. The most exciting thing I did with database snapshots was to create a simple app for my developers to take a snapshot (without needing to know the T-SQL behind it), make whatever changes they needed to, and then roll back or roll forward the changes.

Comments closed

Viewing the File System of an ADO Pipeline Agent

Justin Bird goes spelunking:

There are several predefined variables that you can use within an Azure DevOps pipeline, some of which allow you to reference locations on the pipeline agent file system. Examples of when to use them might be to pick up a file from the downloaded repository or to describe where to output a build. For example the variable $(Build.ArtifactStagingDirectory) will be replaced during the defining of the pipeline job with the respective filepath.

I find it difficult at times to work abstractly with the file system, and so I use this template to visualise the file system for debugging purposes, to observe the outcome of my code, and to make sure I’m picking the right variable.

Click through for some more information about pre-defined variables and a code snippet Justin uses to view filesystem details.

Comments closed

Script Tasks in Azure DevOps Pipelines

Justin Bird builds a script task:

There are several dedicated script tasks that can be used for different purposes, some of the tasks have shortcut tasks which require much less input and are arguably easier to read. In the examples below, I have included the required inputs needed to run the scripts but in most cases, other optional inputs are available.

This looks pretty similar to the way you’d do it in GitHub Actions workflows as well—no surprise there, considering that the same group of people who built pipelines in ADO handled Actions in GitHub.

Comments closed