First published on MSDN on Sep 30, 2016
Authored by Alex Mang
Back in the days of Team Foundation Services (2013 and prior to that), everyone was asking for a way to make Release Management expand to other project types rather than .NET and VB/C++. Taken this feedback (along with many other requests) Microsoft rewrote Team Build. Personally, I believe the entire DevOps story using the Microsoft Stack has become more mature than ever and ready to solve the most complex requirements your application has. In order to achieve this type of extensibility, Team Build allows one to add features in two ways: (1) by installing extensions which can either be wrote and uploaded by yourself or by installed from the Visual Studio Marketplace or by (2) taking advantage of the TFX Command Line Interface which allows you to add custom designed tasks. The latter is especially useful when it comes to creating a single-task functionality as an atomic process part of the build or release definition, rather than leverage several tasks individually. This ensures that in the situation of build and release processes which have to do the same tasks over and over again a few times are easily configurable and thus reduces the error-prone nature of a highly-configurable workflow system, such as Team Build.
The beauty of these tasks are that they are not exclusively designed to Microsoft-specific products and services - in fact, most of the tasks which have to deal with external services will specify the external service's endpoint in the form of a connection setting which is team-project wide. Again, this helps prevent errors related to connection strings and such.
These connection settings are known as Service Endpoints and can be configured from the Settings pane of any team project, both in Visual Studio Team Services and Team Foundation Services, under the Services tab.
One of the most interesting Service Endpoints I ever had to configure were related to either Azure and Visual Studio Team Services - and between the two of them, I do have to admit that the latter seems like the most illogical one: why would you add within a Visual Studio Team Services tenant a set connection settings to... itself? I'll cover that in just a minute!
The shared opinion among ALM experts when it comes to release pipelines is that there should *ALWAYS* exist a least two environments (usually three!) to deploy the application two. In addition, in my personal opinion, it is absolutely necessary to make sure that these environments are exactly the same infrastructure-wise and therefore, should the architectural changes be incorrect, you will fail fast rather than late in the pipeline. Besides that, always make sure that there are no changes from the architectural perspective between these environments. A common way to use these environments is based on the reach and scope of the testing process. Usually, a DEV environment will be created first to make sure that besides the integration tests, the application which is due to be delivered is compliant to all the acceptance criteria; and considering that there's only so much you can do when it comes to integration testing, Selenium tests and so on, having a completely working environment to test upon from a dev's perspective is absolutely necessary.
If you deploy your application to Azure, whether you're deploying it to IaaS (VMs) or Web Apps, a connection to Azure will be necessary. Based on the task type, you will have to configure one of the following two Service Endpoints for Azure: Azure Classic or Azure Resource Manager. The difference comes from the nature of the service you're deploying or the type of cmdlets the tasks is going to call during its execution - of course, the difference itself comes from the changed nature of the entire Azure ecosystem.
There are two ways to configure a Service Endpoint for Azure Classic: credentials and certificate based. Here's how they work!
In order to configure an Azure Classic Service Endpoint using a set of credentials:
Because of the nature of ever changing password of user credentials (hopefully!) and the requirement to use an elevated account part of the directory, I usually recommend against the aforementioned method. Instead, the use of a certificate based configuration is preferred. In order to configure an Azure Classic Service Endpoint using a certificate based configuration:
As a best practice, mark the name of the automatically-generated certificate correspondingly within the Azure Management Portal, so that you can easily locate it should you ever require to remove it. By default, the name of the certificate will map to the name of the subscription and it will be nearly impossible to tell which certificate to select when you want to have one revoked.
Whilst adding a connection for Azure Classic might seem somewhat criptic because of the large number of setting and little available documentation, when it comes to ARM connections, a thorough blog post on MSDN explains the steps you need to take: https://blogs.msdn.microsoft.com/b/visualstudioalm/archive/2015/10/04/automating-azure-resource-gro... .
As a quick review, please be reminded that if you've backed your Visual Studio Team Services tenant to Azure, you will automatically see the subscription ID and name as required fields - otherwise, go ahead and manually configure the integration of you VSTS tenant towards Azure. This can be either achieved by manually creating a Service Principal within the Azure Active Directory directory the subscription is associated to and afterwards by configuring the service principal as a subscription contributor - don't worry if this service principal doesn't show up automatically as it will right after you type in the name of the Service Principal.
Indeed, it might sound strange to configure a connection towards VSTS from the settings pane of a team project which exists inside the same VSTS tenant. However, if you want to take advantage of tasks related to web testing or load testing your application (which is another yet feature of VSTS), you will need to configure the connection to VSTS within the task itself. The curious part however is that the list of service endpoint types doesn't contain 'Visual Studio Team Services' (or any of it former names); instead, a generic service endpoint type is required.
When you configure a new Generic Connection, some settings are required:
In order to configure the alternate credentials, click on your name in the upper-right corner, select Security and click on the 'Alternate authentication credentials' link in the upper-left corner. Make sure the 'Enable alternate authentication credentials' setting is checked, type in a name and the chosen password twice. Click 'Save' and you're all set.
The use of Service Endpoints enables many new scenarios and allows TFS and VSTS communicate with external services. It may sound strange that VSTS requires a connection both towards Azure (considering that VSTS is commonly backed by an Azure account, as a best practice) and VSTS (because... what?!), but in fact this enables even more scenarios such as one in which to share a single VSTS tenant and Azure subscription to pay for cloud load tests but still isolate team projects among multiple VSTS tenants.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.