When I recently heard the announcement for Public Preview of PowerShell in Azure Functions 2.x, I was excited to give it a test drive. One of the first use cases I thought of was using this for custom scripts that run on a build server. For example, a PowerShell script that generates some sort of report and emails users with the results. Rather than running this on a build server, we can use Azure Functions to reap some of the benefits of serverless. In this post I’ll walk through setting up an Azure Function that’s triggered by an Azure Pipelines release definition via HTTP.
If you’re attempting to update a sprawling amount of release definitions, clicking through each definition using the visual designer can be a real chore. That’s why Task Groups really come in handy…But if you’re already stuck with a bunch of definitions that don’t utilize task groups, you’ll probably want to turn to the REST API using PowerShell.
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).
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.
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.
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.
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.
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.
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.