To deploy resources on Azure using VSTS as part of ci/cd process, first VSTS needs to establish an connection with the Azure and ensure it has proper permissions to manage resources. For this purpose, if you are using VSTS to manage azure resources, you would need to create an Azure Service endpoint first. In this blog post, we’ll learn how to do the same.
If you are doing in this your personal subscription, you will probably already have required permissions on Azure AD. In that case, you can skip directly to section: Create Azure endpoints in VSTS and use short version of dialog only. VSTS will automatically query and create required configuration for you. If you are working with medium or large sized organizations, you’ll need to create it via long way which provides more granular level of access and control. Continue reading “Create Azure service endpoint in VSTS”→
VSTS or Visual Studio Team Services is a great DevOps tool from Microsoft and it comes as a Software-as-a-Service. While configuring build pipelines, once can choose the option to build and deploy using a hosted agent. A hosted agent is provided by Microsoft and is pre-configured with all major build tools installed like Visual Studio, Java, Ant, etc. So for many organizations, this is the simplest way to build and deploy.
However, the hosted agent might not suffice for your needs. For example, you may want to use your own testing engine or compilation engine, or you are working on a not so common programming language, etc. In such cases, you will need to setup your private build server. Private agents give you more control to install dependent software needed for your builds and deployments. In this blog post, we’ll learn how to add a build server to VSTS and also configure it for build capabilities.
n this blog post, we’ll discuss how to configure CI/CD for dockerized apps using Visual Studio Team Services (VSTS) and deploy to a Linux based kubernetes cluster in Azure Container Services (ACS). For building dockerized app, we’ll use .NET core and build a linux based docker image. Also we’ll be using Azure Container Services to deploy Linux based Kubernetes cluster and Azure Container Registry for providing docker registry.
Whenever a new .NET assembly project is created in Visual Studio, a file named AssemblyInfo is created that contains attributes used to define the version of the assembly during compilation. Using assembly versions effectively enables various team members to identify deployed assemblies and helps troubleshoot problems that may occur in a particular environment (e.g. Development, Test, or Production).
When building the solution, there are two version numbers that need to be considered: the file version number and the .NET assembly version number. As part of the best practices, the AssemblyFileVersion attribute should be incremented automatically as part of the build process. It is therefore intended to uniquely identify a build. The AssemblyVersion attribute is the version that .NET uses when linking assemblies. In this blog post, we’ll learn how to use the build process to auto specify the AssemblyFileVersion and AssemblyInformationalVersion.
We recently came across this problem. One of the developers had created a new branch in the one of the source code repositories hosted on the Visual Studio Team Services aka VSTS. Other developers were unable to see this newly created branch in their visual studio team explorer pane:
In previous blog post, we learned how to do baby steps for implementing IaaC. We learned how to use ARM templates, Git and Visual Studio to code your subnets in the Azure. Now, there is no doubt that Git has taken over the world for source code management. And while it is good for managing versions of source code, those versions and details are confined to your local machine. If someday your local machine goes kaput, its all in water. For that, you need to sync your changes to a centralized source code management system. Also having centralized source code management allows more than one person to work on the same repository.