Making Schema Modifications Using Database Change Scripts
In this post, we’ll examine some popular strategies for updating database schemas, including using database change scripts. We’ll also see how one of these strategies can be integrated into a deployment process that uses Octopus. This is the fifth post in a multi-part series about using Octopus Deploy.
Databases are a key part of many applications. Naturally, releasing a new version often requires a schema change. One way we can accomplish this is to use change scripts, so we’re going to look at how this works. We will see how to name and organize change scripts so they are deployed in the proper order. And we’ll also briefly touch on how Octopus supports a change script strategy.
In our last post, we explored lifecycles in Octopus Deploy. In this post, we’ll examine Octopus Deploy projects and project groups. We’ll see how projects help to define your deployments. We’ll look at how project groups help organize your projects, and also how they play a role in providing security. And we’ll also see how an Octopus project uses a lifecycle to control a project’s deployment model. This is the fourth post in a multi-part series about using Octopus Deploy.
When first trying out a new application, it’s tempting to jump right in. Often, you can learn a lot about a new system through usage and discovery. However, Octopus Deploy introduces a new vocabulary that needs to be understood. In particular, two concepts that crop up constantly are environments and roles. This post will provide a magic decoder ring.
I started out my career several years ago as a build and install engineer (remember InstallScript? Yeah, me neither.) Today, I create web applications for a large urban county government. Naturally, we need to deploy these applications to various servers. So, like many dev shops, we’ve created our own home-grown deployment processes. Maybe you have too. We’re developers, after all!
While our processes work for us, they had become a bit unwieldy (see Figure 1.) They were also difficult to maintain and needed updating. In addition, we were starting to consider a move towards the cloud. The systems we’ve been using do not address this need at all. As a result, it was time to up our DevOps game.