On September 10, 2018, Microsoft announced Azure DevOps, which is the next phase of software delivery. Azure DevOps is the next evolution of Visual Studio Team Services (VSTS). Quick side note, VSTS users will be upgraded automatically to the new Azure DevOps structure. It will help organizations delivery faster and with high quality across a wide breath of the development life-cycle and systems.
Let’s see the official announcement from Donovan Brown the DevOps Manager at Microsoft.
Azure DevOps will include the following:
- Azure Boards – a powerful way to track deliverable through boards, backlog, dashboards, and reporting.
- Azure Repos – an unlimited cloud hosted repositories for source control and collaboration.
- Azure Artifacts – Various development package feeds from public and private sources like npm and NuGet.
- Azure Pipelines – CI\CD that can deliver to any language, platform, or cloud.
- Azure Test Plans – Testing, Testing, Testing – all in one solution.
Each Azure DevOps service is open and extensible and works great for any type of application regardless of the framework, platform, or cloud. Learn more about cost from Azure DevOps Pricing.
Here is Edward Thomson, the Program Manager for Azure DevOps discussing Azure Pipelines, which is on of the key pillars in Azure DevOps.
There are some key changes to this transition of VSTS To Azure DevOps that you will see:
- URLs will change from <name>.visualstudio.com to dev.azure.com/<name>.
- Services will have an updated user experience.
- On-premise TFS will receives updates based on new features and will renamed to Azure DevOps Server.
You might want to visit the save-the-date and watch live streams on Azure DevOps events page. There you’ll also find additional on-demand videos and other resources to help get you started using Azure DevOps.
Recently I inherited some poorly written WebJobs that I needed to create an automated deploy for a client to their various environments (DEV, QAE, and PRD). To start the WebJobs were missing the publish package required to publish them to Azure, which is added either by the package manager (seen bleow) or the Publishing via Visual Studio (using 2017) Publish.
You can add the publishing package from NuGet by running the following command in Package Manager console:
Once that was completed, we need to head over the Visual Studio Team Services (VSTS) to create a build and release for these WebJobs. The tests were disabled as there were not any in the project and planned to add them in the future.
You only need to do a few modifications to canned build template; however, I did add some build arguments as follows:
/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=false /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactstagingdirectory)\\Webjob Deploy" /p:PackageTempRootDir="\Web"
One of these arguments changes the deployment path to “Webjob Deploy” and in the Publish Build Artifacts task I change the Path to Publish to the following:
Once I ran the build my artifacts looked like:
Once this is complete we can head over to my build the release for the WebJob code. We start by linking the artifacts and create an environment, I general start with one to get it working and tested then clone it and change the variables for that environment.
Part of the release was that I needed to create the Azure Resource Group and deploying all the components then linking my deployment artifacts to my these resources (App Service and App Service Plan). I plan to add a blog post on DSC (Desired State Configuration) scripts and ARM (Azure Resource Manager) templates, so more to come.
Hope this journey helps!