A couple of days ago Microsoft announced about the first RC of Azure DevOps Server 2019. The news is quite exciting, and I decided to dedicate one of the evenings to my review and dig a bit deeper using an empirical approach. The first reasonable question you may ask, what’s the point in having Azure DevOps if we still have TFS for the on-premise deployments that has roughly the same capabilities, similar to its cloud ‘brother’? Well, Azure DevOps Server is the new name for the on-premises DevOps server previously known as Team Foundation Server (TFS) so, after v2018.3 TFS ceased its existence.
The one may wonder what’s the difference between the Azure DevOps in the cloud and this one? There is none. The cloud-based version of a product has leaped implementing several new features and improvements, including a complete UI redesign which is the most noticeable. TFS had to catch-up, and Microsoft has killed two birds with one stone: renamed the brand name to align the offerings and brought all the new features to Azure DevOps for on-premises deployments.
Once I’ve downloaded the internet-based installer from the official website, the installation has started. The process is quite straightforward… a couple of clicks and you can relax for several minutes observing how the wizard downloads external dependencies and installs TFS… excuse me, Azure DevOps 😊
The reason I said TFS is not coincidental. The installation experience along with the configuration wizard is quite the same to those from the latest TFS (aside from the labels, of course). For the clean installation I’ve chosen a DS2v2 VM in Azure and spun-up Azure SQL. It seems I hasted a bit pre-installing Azure SQL because this option was unavailable in the wizard (despite the announcement):
I had to tier Azure SQL down and use similar VM with SQL Server 2016 EE image to deploy it. This review doesn’t cover the Azure infrastructure deployment details, although, it worth to mention that I used the same VNet and configured SQL Server VM, so it has a private connection within the same virtual network which is perfectly fine for the sufficient level of security and our little experiment.
Do not forget to add an exception in Network Security Group for your VM, so it can access database on port 1433 and enable a Full-text search service in SQL Server as it’s a mandatory pre-requisite. Having reporting services is optional as long as the integration with SharePoint services. I left the rest of the settings by default and did a readiness check:
It seems that a multi-server installation is not supported with VMs not included in Active Directory domain, which makes sense. I had to extend my cloud deployment a bit to host the AD Domain Service and peer another VNet so I can connect two existing VMs to it. For the Azure DevOps Server deployment, I ended up with the following configuration:
Installing JRE 8 (x64) to complete configuration is not a big deal and after the next check everything works like a charm:
Configuration takes time so you can just relax in your chair and observe the process, or do something in parallel 😊
The server’s webpage will be available by the following address http://<devops server ip>:8080/tfs. Don’t be fooled. It is still a plain old TFS in the new ‘skin’ and the official documentation is still riddled with the old screenshots and links to TFS-related resources.
A picture worth a thousand words. Let’s see what we’ve got here:
At a glance, there are no differences between on-premise and Azure-based version of the product. Although, one thing is pretty noticeable – ‘organization’s settings’ menu is not there. There is no multi-tenant concept in the on-premise version. If you’d like to achieve a logical separation between the organizational units, the separate collection would be a way to go.
Continuing my review, I decided to build a full CI/CD pipeline using DevOps Server. I have committed the code to Git repository
and proceed with the pipeline that is supposed to build and package a front-end application that uses Angular 7:
The pipeline is fairly simple and everything it does is npm packages restore, solution build and running tests. The packaged solution then is passed to a release pipeline which comprises of one step (deployment to a WebApp) so I decided not to publish it here. Although, the point of interest here is a Linux build server I used to build the solution. It is a Linux Ubuntu VM with pre-installed dependencies for testing and zipping the code. Due to the relative complexity of the Build server deployment, it deserves a separate topic which I post next Friday 😊 To access your subscription, you have to create a Service Principal in Azure DevOps and the process in full is well described in one of my previous topics: https://strive2code.net/post/2017/06/29/creating-a-service-principal-for-vsts-endpoint
Having in mind the build server and a WebApp in the same subscription, the reference diagram is changing to the following:
After a successful build the solution was published to a respective WebApp:
Wrapping up
First impressions about DevOps Server are absolutely positive, even though one of the announced features doesn’t quite work yet (Azure Database deployment). Some of the TFS-related inconsistencies (installer, documentation, splash-screens etc.) are quite eye-catchy but don’t spoil a really good and so much familiar product, and you should remember this is just an RC1 (so, not yet a retail version).
So, who may need this product? Well, if you’re obsessed with security, want absolute isolation from the external world and ready to put up with administrative efforts (not only management but also supporting HA/DR), this platform is for you. You can deploy it anywhere or even consider a hybrid option, but having it deployed to Azure I came up with the following calculations, to provide you with a better understanding of capital and operational expenses:
Given that selected VMs going to cost 0.175/h and Azure AD Domain Services is $0.15/h + separate build servers, and there are approx. 730h in a month, the calculation would be the following:
VMs $127.75 x 2 + Azure AD Domain Services (~$110/month) + network infrastructure + bandwidth gives ~$400/months + admin efforts. Having in mind that the server must be highly available and durable, the price would be even bigger.
Would be a bit cheaper with BYOL program.
References
https://docs.microsoft.com/en-us/azure/active-directory-domain-services/active-directory-ds-admin-guide-join-windows-vm-portal
https://azure.microsoft.com/en-us/services/devops/server/