In order to gracefully deploy releases to our application servers, I wanted to utilize rolling deployments in Octopus Deploy. If you aren’t familiar, rolling deployments slowly roll out a release one instance at a time (vs. all instances at once). The goal of this being reduced overall downtime. To accomplish this, I wrote PowerShell scripts to leverage AWS Auto Scaling Groups (ASG) that are run as part of Octopus deployments.
Last week Microsoft announced “Pipeline as code (YAML)” giving us the ability to store our builds in source control. This allows us to take advantage of Configuration as Code as well as other benefits not available through the Visual Designer builds:
My team wanted the ability to populate test data into new data warehouse instances (MySQL on Linux) that are created via Infrastructure as Code (CloudFormation and Chef). They already had the SQL scripts they used for local development, so I would just need to setup a process to package and deploy them. This process would then be automatically triggered when a new instance is created.
This past week I started concentrating on optimizing our release processes. I’ve talked about how our team uses VSTS and Git in a previous post. At the end of a sprint, pull requests are created in all of our repositories to merge to the release branches. As the number of our repositories continues to grow, the number of manual steps to merge for releases grows exponentially. Having worked with the VSTS REST API in the past I knew this wouldn’t be difficult to automate. A build would be run that runs the script below for each of our repositories to create pull requests. Service hooks to Slack would then send notifications so the necessary reviewers can approve the newly created pull requests. This same script can be used post release to merge back to Master branches. I commented on every line of code in the script below so I didn’t have to go into details here 🙂
I previously posted about how I discovered LaunchDarkly and wanted to introduce it at my current employer. See Part 1 here. Our pilot with LaunchDarkly went great. So great that we purchased a subscription.
If you’ve installed or used private builds agent for VSTS or TFS, you’ve probably noticed the Agent’s System Capabilities are listed in the Agent Pool hub (https://ACCOUNTNAME.visualstudio.com/_admin/_AgentPool):
At DevOpsDays Minneapolis I was the facilitator for an Open Space discussion (largest group of the day!!) on my proposed topic of “Release Management and Deploying to Prod Multiple Times a Day”. More on what an Open Space discussion is here. I received a ton of really great feedback on my employer’s current processes and what we can do to move to a faster release cadence in the future. The TL;DR of the discussion was, use feature flags!
Continue reading Feature Flag journey with LaunchDarkly – Part 1
Weather you’re using AWS Lambda, Azure Functions, or Google Cloud’s Firebase, you’ll want to re-think how you approach configuration management for serverless projects. The number of projects tend to grow fast because a microservice architecture is most commonly used. This introduces a new set of configuration management problems. Manual tasks to create and manage these projects grows exponentially. Without proper configuration management these projects can quickly spiral into the wild wild west. I’d like to review the principals of SCM and share some solutions for accomplishing these goals when working with serverless/microservice projects.
The majority of developers spend most of their time in Visual Studio and don’t have to understand what happens under the hood with MSBuild. Click the play button and magic happens! However, you may need to troubleshoot a failing build or extend the build to automate things. For those scenarios I’d like to provide a quick intro to what MSBuild is made up of and some tips on troubleshooting. Note: I’ll be using some of the code snippets from the Microsoft docs.
The trace-ability features when linking between Octopus and TFS/VSTS work pretty well out of the box, especially when using the Octopus Deploy build extension. When Releases are created by a build, there is a link in the Release description that points back to the build that created it. There is also a section in the build results that points to the Octopus release that was created. This met most of my needs, but to take it a step further and reference builds/files/artifacts during deploy time, I decided to use the Octopus Deploy API. I wanted to update Octopus variables as part of the build process before a Release is created so that deploy steps could link back to builds/files/artifacts that were versioned during build.