Category: Deployment

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

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

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

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