Today we needed a way to determine build runner usage across all TeamCity projects. We were using a custom build runner – Node.js NPM – in several projects in TeamCity, but we didn’t know exactly which projects. And we wanted to upgrade the version of Node.js on our build server.
The Node.js NPM build runner allows you to integrate Node.js into your build steps. But, unless you’ve configured the related build steps to use a specific Node version, it will use whichever version that is currently installed on the build agent. So if we didn’t pay attention, upgrading Node.js had the potential to break some of our existing build configurations.
In the previous post, we took a look at DbUp – a tool to package and deploy database change scripts. In this post, we are going to check out another tool, OctoPack. We’ll be using OctoPack to help us create and publish packages in a format that Octopus Deploy can easily consume. This is the seventh post in a series about using Octopus Deploy.
An Octopus’ Garden – and Some Turtles
Octopus Deploy has many capabilities. But once I got into to it, eventually I found that three of the shiniest objects in the world of Octopus are:
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.
About once a year I have to set up an entire new application from scratch. To help speed this process along, there are many NuGet packages that we typically use. Since we strongly believe in IOC and DI, one of our more important packages is Ninject.
Sometimes I find myself needing to create a complicated bit of logic in the SQL layer (say, for statistical reports.) Later, perhaps someone will ask to see these statistics exposed on a screen through the UI. Suddenly I need this same logic further up the stack. While I’m a fan of using LINQ, too much code duplication of complex logic can result in a maintenance headache. This is even more true when the duplication crosses languages, as when going from SQL to C#. Staying DRY is a good thing.
While I’d prefer to confine most of my coding logic to C# and keep my databases as simple as possible, sometimes this is not practical. In this article I will demonstrate how to call stored procedures using DbContext.