Azure DevOps

I’ve spent quite sometime to evaluate various CI/CD cloud services, I will try to document them in some posts. And the first one of this series is about Azure DevOps.

What is Azure DevOps

This is a rebrand of Microsoft’s VSTS(Visual Studio Team Services), sometimes I have to search for VSTS instead of Azure DevOps on Google to get relevant result.

They provide a very generous free plan, including 1800 build-minutes(60 minutes per day on average) on their server and one self-hosted build agent(i.e we install the build agent on our server and let Azure manage it). We are also provided with a git repository(not as good as Github though), an issue tracker, kanban board, test plan management. So it’s kind of a full-blown devops solution.

However, the price goes steep when we want to add more parallel builder(agent), both on their cloud or on our server($40 per additional hosted agent and $15 per self-hosted agent).

CI/CD service

There are two seperated services: Builds(CI) and Releases(CD).

With Builds, we describe our build steps in an yaml file and it will be triggered whenever there is new commit, pull request or change in code.

With the Releases, we, however, cannot describe the build step by configuration file and have to use their web interface which sometimes is sluggy and incomprehensible.

I still don’t know why they divide into two seperated categories although they are quite similar.

Functionality and extensibility

Azure provides a variety of built-in tasks ranging from web application, mobile app and connector to other services. There is also an marketplace for third-parties to provide their own build task, for example, I’ve found there AWS relate task such as push docker images to ECR, deploy to lambda, etc.

We can also write our own task using javscript.

So in term of functionality and intergration with other cloud services, Azure DevOps is very good.

However, documentation quality is not that good. Sometimes, I have to dig in the task’s definition in order to get a definition of a parameter.

Another annoying thing is Azure provides no caching mechanism at all. Therefore, everytime the builder kick-in, it will start freshly from beginning. If your pipeline is pulling lots of data/libraries, this could take a very long time. In my case, I have to run Ruby’s bundle install and it takes about 10 minutes only for this task.

Lurking through support forums, there are lots of request for this function since about 2 years ago, but still, no update at the time of this post(2019 Feb).

Right now, I have to roll my own caching which is download my node_modules folder to s3(and upload it after build finished). I hope they will provide a better caching mechanism in the future.

So this is my first impression with Azure DevOps. Overall, it is easy to use and setup, provide a generous free-plan to try; however, documentation is not quite good and the web UI is slow and sometimes, incomprehensible.

Maintainability

As we need to use a propriety agent provided by Microsoft when there is bug in the agent we have to wait for Microsoft to fix it and sometimes this process take lots of time. One incident that I have met is the hosted Ubuntu agent mysteriously couldn’t build our Docker image although previously it had been working flawlessly and I have to wait for about 2 months for it to be fixed¹ during that time there is nothing much that I can to other than using workaround.

That what we have to tolerate when choosing a propriety solution and when we are not their BIG corp customer.