What is Azure DevOps and how is it used for more reliable and scalable service?
What is Azure DevOps?
DevOps is a set of practices (a methodology) that automates the processes between software development, and IT teams so they can build, test, and release software faster and more reliably. Azure DevOps is a Microsoft service that allows teams to manage the development of projects using these practices.
There are many benefits for teams delivering fixes and new features to their software, such as:
- Boards to track tasks/backlog items,
- Repositories to store code and track changes,
- Pipelines for build and release procedures,
- Test Plans for testing,
- Artefacts for sharing packages.
There are also a few critical components to Azure DevOps that every team should be using regardless of whether they work with the DevOps management methodology, and these are Repos, Pipelines and Artefacts.
While working with C# web projects, traditionally, developers use a git repository of their choice to track code changes. While deploying features, a developer publishes the site to a local folder and then copy and pastes that to the server. This manual deployment approach can cause problems for developers and project stakeholders primarily because of human error, e.g. developers not copying all the correct files or not being aware which files get overwritten.
How does Azure DevOps eliminate some of these issues?
All teams who are working on a project will be using a repository to track code changes. Azure DevOps provides a “Repos” service where you can set up multiple repositories per project.
Although Microsoft’s solution is not vastly different to BitBucket or GitHub, it is excellent at ensuring code quality is maintained. With DevOps you can set up branch policies, so you don’t push code to your main branches such as “master” or “staging”, and if your code needs to go to any of your main branches, you will send a Pull Request (PR). To ensure that the team is following robust code quality standards, you can then also set up review policies for Pull Requests.
With “Pipelines” your team can set up a build process which would create an artefact of the build. This artefact can be used to deploy to your Web Application on Azure.
Once your pull request is “merged” into one of the main branches, you can do a deployment, and this is where Azure DevOps can save a lot of time and eliminate human error. With “Pipelines”, your team can set up a build process to create an artefact of the build. This artefact deploys to your Web Application on Azure.
Removing the complexity of creating builds away from the developer ensures that a build does not get released with broken functionality.
An artefact is the compiled files, views, CSS, scripts and anything else your application needs to work on your environment. As a developer, you can configure your build process to compile all the code, minify your CSS and JavaScript, run unit tests and much more. You can apply triggers to start automatic builds as soon as you apply a change to the branch. This process is called Continuous Integration (CI) and ensures the creation of builds for your releases as soon as something new gets added. Removing the complexity of creating builds away from the developer ensures that a build does not get released with broken functionality.
Once a build has completed successfully, a release pipeline trigger can automatically deploy the build to your environment, this is called Continuous Development (CD), and apart from saving time, it can also prevent human error caused by manually deploying. Releases will no longer need to be scheduled well in advance, and any developer who has access to the Pipeline can trigger a build and a release reducing reliance on a single developer and improving release times.
The process described in this article ensures code quality and reduces human error. Coupled with a cloud infrastructure provider such as Azure this can save organisations time and money. Ensuring better code is applied to your repository and removing the reliance of manual deployments will always provide some (if not significant) benefits to your company.
Azure App Services
Connecting a Release Pipeline from Azure DevOps to an Azure App Service is very simple, especially if using the same account. If you need to connect Azure DevOps to an external Azure account, then a service principal will be set up just for deployments and added to Azure DevOps via a key and secret provided by the administrator of the Azure account.
As the builds and release are done on the Azure DevOps site using an agent, a machine dedicated for doing builds, releases and other tasks; the typical downtime for a deployment is minimal. The App Service will only be unavailable while the files are being copied over by the Azure DevOps agent and while the application restarts.
Azure Web Application Scaling mitigates downtime, and Azure Web Applications can be scaled to provide more instances for your site while the others are updated.
Due to Azure only charging for what you use, there is potential for organisations to save money. However, this is not always the case; especially if you have a high traffic website. For example, if you see hosting prices rise after moving to Azure, do not assume that it must mean this is the more expensive option. Resources could be set up incorrectly, or the site might be set up with higher specification resources giving your users a better experience.
In conclusion, Azure services can provide many benefits to developers and clients alike. The Azure DevOps service reduces human error by providing automated processes modified to specific preferences. Furthermore, the services Azure provide can be scaled up/down out/in to potentially save money and give a better overall solution, optimised to your website usage.
The advantages of using Azure DevOps with Azure over traditional manual processes are clear. Because of this, we actively encourage the use of Azure DevOps and Azure for every single one of our projects.
