A blog about things I learn at the keyboard: DevOps, CI/CD, Cloud, Automation, to name a few….
I recently setup a new SonarQube instance to perform static code analysis as part of CI builds. In this post I’d like to document what I learned to hopefully make it easier for you (I assume that’s why you’re reading this).
Continue reading Setting up SonarQube (on Windows) with Azure Pipelines
The filtering options on the release pipeline dashboard leave a lot to be desired. As the number of definitions and releases grow, it gets harder and harder to have overall visibility across releases. Currently there isn’t a great reporting solution that can be used to gather such info.
Continue reading Azure Release Pipelines: What releases haven’t been deployed to Production yet?
In the past, I’ve used the method of placing a app_offline.htm file at the root of an IIS website to throw up a maintenance page. This has been available since ASP.NET 2.0 / 3.5. Lately I’ve got used to deploying sites with no downtime approaches, such as rolling and blue/green. I had forgot about app_offline.htm when I recently set up deployment pipelines for some ASP.NET Core sites.
Continue reading Deploying IIS hosted ASP.NET Core apps using app_offline.htm
I recently had to come up with a solution to perform a bulk deploy of all apps to an environment using the latest build artifacts. I wanted to use a “wrapper” release definition to orchestrate all of the deployments; similar to how Octopus Deploy’s “Deploy Release Step” works.
However, TFS Release Management currently lacks functionality to create releases from within a build or release definition. There are 3rd party extensions to queue/trigger other builds within a build definition, but nothing to create releases.
Continue reading TFS Release Management: Create Release via REST API
The new TFS/Azure Pipelines build and release tasks to run functional tests make setting up a CI pipeline pretty dang easy. The VSTest task can now run unit tests AND functional tests. Microsoft deprecated the “Run Functional Tests” task in favor of consolidating all things test related. In this post I will outline the steps to: trigger a CI build that builds and packages your functional test project, executes the tests, then provides test run results. This will be fairly high level and I’m going to assume you already know the basics of installing agents and creating build/release definitions.
Continue reading Setting up a CI pipeline to run functional tests in TFS 2018 and Azure Pipelines (Formerly VSTS)
The semantic versioning used in all of our TFS/VSTS CI builds uses the predefined variable Build.BuildID for the buildnumber portion of major.minor.revision.buildnumber. The build id is used so we have traceability when troubleshooting. We can easily search for the build and see the associated changes. Major.minor.revision is set in a variable group so it can be shared and updated in one place, across build definitions.
Continue reading Versioning .Net assemblies using TFS/VSTS Build.BuildID
I recently set out to automate the creation of our Windows build servers that run VSTS agents. Previously the build servers were thought of as “snowflake” servers because of all the software components and customization’s that were needed. This was even more reason to use Infrastructure as Code to get rid of manual run books that were previously used to document the creation of a build server. Our Infrastructure team already decided on a tool chain for Infrastructure as Code, which included Chef for Configuration Management.
Continue reading Chef recipe to install VSTS agents (Windows)
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.
Continue reading Rolling deployments to AWS using Octopus Deploy and Auto Scaling Groups
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:
Continue reading Azure Pipelines YAML Builds (Pipeline as code)
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.