In last few posts of series of articles on the Git, we discussed several ways to work with code in our local repository. We learned about commits, branches, merge, rebase, stash and whole lot of other commands. If you want to see all those posts, just filter using Git category appearing in left pane in this site. However for most of the time, while working for an complex software, you would be working along with other developers. Therefore, you need a central place where you could host all of the source code and then you need some ability to download/upload your part of the code. This is where in the cloud-based Git repository providers like BitBucket, GitLab, GitHub, Azure Repos etc or On-Premise based Git repository providers like Azure DevOps / TFS, GitHub Enterprise , etc fits in. We already have learned the ability to segregate code for different features/issues by using concept of branches and tags. Continue reading “Work with remote in Git to share your code”
You can easily store your environment related secrets in the Azure Pipelines releases as variables and mark them as secrets which will encrypt and hide them. So anyone having access to the release definition would be not able to view them. Most of the times, it suffices as once set, they become encrypted and can not be viewed in text form.
However, sometimes it may happen that the person who keeps the secret would not be the same person as who is creating the release definition. Think of that as a way of segregating the responsibilities between the two. Also, it may be possible that the person who has provisioned the environment is not comfortable to share the secrets with anyone in plain text. After all, the best way to keep a secret is not to tell anyone about it. This is where the Azure Key Vault fits in very nicely. It can be used to store and transfer the secrets/certificates needed for your environment in a secure way.
Continue reading “Store the app secrets in Azure Key Vault and use during Azure Pipelines”
It has been long since I have written blog post about using Nuget Package feeds in VSTS, which can be found here. I have always wanted to write a follow up blog post about how to use feeds further but I was occupied by other priorities and then it fell off my mind. Since then VSTS has been renamed to Azure DevOps and Package feeds are now known as artifacts feeds. However, other than this, most of the things and functionality has been more or less intact in terms of this feature.
For this who are not aware of the Nuget, it is a technology which works on the principal of the package management and very helpful for code sharing in .NET framework and .NET Core based applications. Continue reading “Create Nuget Packages using CI/CD in Azure Pipelines and push to Azure Artifacts feeds”
Few days back, we learned about how to publish Azure Container Instances where-in we can deploy either a container or group of containers and use the same. Azure Web App for Containers allows you to not only run your containers but it also brings forth the PaaS innovations for the Web App. So it brings best of the both worlds together. It also allows you to not worry about the maintaining an container orchestrator mechanism. You can prefer to package their code and dependencies into containers using various CI/CD systems like Jenkins, Maven, Travis CI or VSTS, alongside setting up continuous deployment web hooks with App Service.
In this blog post we’ll learn more about how to deploy .NETCore application packaged as docker container and using CI/CD in Azure Pipelines (Formerly VSTS). Continue reading “Configure CI/CD in Azure Pipelines to deploy docker containers as Azure Web App”
Containers are fast becoming the preferred way to package, deploy, and manage cloud applications. Azure Container Instances offers the fastest and simplest way to run a container in Azure, without having to manage any virtual machines and without having to adopt a higher-level service.
Azure Container Instances is a great solution for any scenario that can operate in isolated containers, including simple applications, task automation, and build jobs. Also, Azure Container Instances supports the deployment of multiple containers onto a single host by using a container group aka pods in terms of Kubernetes. Multi-container container groups or Pods are useful when building an application sidecar for logging, monitoring, or any other configuration where a service needs a second attached process.
Continue reading “Configure CI/CD for Azure Container Instances using Azure / Azure DevOps Pipelines”