Since in last post, we discussed on how to run Azure Pipelines agents as docker containers and configure them accordingly, the next step would be to run them on the Kubernetes platform. This kubernetes cluster can be on-premise and/or cloud and could be self managed or managed by the cloud service provider itself.
One of the reasons you may want to run them on Kubernetes is because you want better utilization of your kubernetes cluster. Another reason might be to leverage your existing knowledge of the kubernetes platform and work on it. Another reason would be to not use Microsoft hosted agents, as by default you would get only 1800 minutes of agent time to utilize, for free accounts.
Continue reading “Run Azure DevOps Private Agents in Kubernetes Clusters”
To run the build or deployment jobs in Azure DevOps or Azure Pipelines (formerly known as TFS and VSTS respectively), an agent is required. Microsoft provides the different types of the agents and they are hosted and managed by Microsoft only. However, it is advisable to host your own private agent for various reasons other than the cost. Microsoft provides the facility of installing agent on various OS’es like Windows, Linux, Mac OS etc. They have done a good job in terms of documentation, however you still need to perform few steps in order to set it up correctly.
Continue reading “Running Azure DevOps private agents as docker containers”
When configuring your Build Definitions on Azure Pipelines or on Azure DevOps server, you can configure a Continuous Integration (CI) build. A CI build runs for every checkin or commit that you make to source control. This allows you to start an automated process that for example compiles and deploys your build. This is a very useful process and it should be ideally setup in the above way. However there are times when you do not want the check-in to trigger a build at all. Continue reading “Prevent the Continuous Integration build in Azure Pipelines after pushing commit”
It is easy to create variables in the Azure Pipelines and they make the pipelines more generic in nature. Therefore, we can customize the release steps as per the context of the stage used. Same goes for the build definitions. Now sometimes, it may happen that the variables are common across multiple build and release definitions. In such a case, instead of defining them again and again, we can use a variable group. A variable group allows us to store values that we want to make available across multiple build and release pipelines. It also prevent duplication of values, making it easier to update all occurrences as one operation.
Continue reading “Share variables across definitions in Azure Pipelines by using variable groups”
In previous post, we discussed about how to work with remotes in Git at command line. In this post, we are going to discuss how we can do the same from the very comforts of Visual Studio while we continue to host our source code on the GitHub. While it’s true that there is no command or built-in option available in Visual Studio to connect to GitHub, we can leverage one of the extensions available for GitHub.
Install GitHub Extension for Visual Studio
To search for this extension, let’s open Visual Studio first. From the tool bar menu, select Tools and then click on the ‘Extensions and Updates’:
Continue reading “Working with remotes in Git, GitHub and Visual Studio”