Integrating On-Premises Jenkins with VSTS to deploy to an ILB ASE


I recently had to work on integrating an on-premises Jenkins with VSTS in order to use VSTS’s out of the box capabilities to deploy resources to Azure. Although there is quite a good documentation on this topic, you must be able to read between the lines. So, with this blog post, I’m not going to repeat was is described in the article but I’m going to try to fill the gap when it comes to integrating with an on-premises Jenkins and not with a Cloud-based Jenkins, as assumed by the Microsoft documentation. Since an image tells more than a lengthy speech, here is one that sum it up all:

Continue reading

Posted in Azure, DevOps, vsts | Tagged , , , | Leave a comment

My recipe to build secure applications hosted in Azure


Here are some tips that might help you building and hosting secure applications in Azure.

Application Architecture: Clients and APIs

Make sure to make a clear segregation between clients and APIs. I’m not a great fan of MVC where the C part is often used as an API layer by developers. I advocate for a clear separation between the client part (could be a mobile APP, a SPA, etc.) and the API layer. The clients and APIs should be hosted in different App Services.

Continue reading

Posted in Azure, Azure Active Directory, Azure Key Vault, Security | Tagged , , | Leave a comment

Azure Security Cheat Sheet


Cybersecurity is a concern for everyone today as more and more workloads are connected in a way or another, meaning exposed in a way or another. When it comes to the Cloud, things turn wilder as PaaS, CaaS, FaaS and even IaaS to some extent, represent a paradigm shift. Organizations tend to rely on good old recipes that are perfectly suitable for traditional on-premises systems but not especially a good fit for the Cloud, even when talking IaaS, since the underlying network plumbing does not have much in common with on-premises networks. Moreover, insiders represent a severe security risk but some organizations still think their premises is way more secure than the Cloud, just because, it is within the walls.

Continue reading

Posted in Azure | Tagged , , | Leave a comment

Deploy Azure App Services to multiple regions within the same subscription – VSTS trick


Most of the times, when deploying App Services such as a webapp to a single region, you simply use the Azure App Service Deploy task, that is currently in version 3.0 and whose a preview of the next version is to come.

However, using the very same task to deploy an App Service to multiple regions, in case you have a HA setup is a little more challenging. Looking at the below screenshot:


you can easily specify the name of the App Service. The problem is that, when working with multiple regions, the name will most probably be the same in the other region, therefore, the task cannot distinguish which service is targeted.  So, ideally, we should be able to select the resource group to make this distinction.

It turns out that one can select the resource group when ticking the Deploy to slot option:


but what if you don’t use slots??? Then, the easy fix is to put the value “production” in the Slot field.

Credits to Thomas Browet (@thomas_brw), one of my colleagues, for the tip.

Happy deployments!

Posted in Azure, DevOps, vsts | Tagged , , , | 2 Comments

VSTS task/extension upgrade explained


There is quite good documentation on Microsoft web sites on how to build custom tasks and custom extensions but things become a little more complicated when it comes to upgrading existing tasks and/or extensions. Since I ended up reverse engineering extensions built by big third parties (by downloading them), I thought it was well worth a blog post to prevent you having the same pain.

That said, you have to distinguish the tasks & extensions. For a private use, one can perfectly work only with tasks. Extensions are a way to distribute one or more tasks from the market place, either for a private share, either for public share. I will only consider the latter.

Fixing a bug

If you want to fix a bug of an existing task, you can simply upgrade the patching or minor version number and upgrade the extension number in the manifest.

"version": {
"Major": "1",
"Minor": "0",
"Patch": "1"

Updating the extension in the Management Portal (I’ll come to this later) will automatically make the build agents of accounts consuming the extension, picking up the last version of the task.

Publishing a major version of a task

If the change is bigger than merely a bug fix and if you want to have task versions side by side to avoid breaking anything or to propose multiple versions of a same task such as:


you’ll need to work a little more. In that case, you can duplicate your existing task but end up with a folder structure like this:

my task
—-v1 artifacts
—-v2 artifcats

The task identifier must remain the same, the name may be left unchanged or be changed and the major versions must be different. In the extension manifest, the contribution should refer to the root folder of the task and its identifier like this:

"contributions": [
      "id": "ca1755b2-751f-45e3-9bad-89a5c08d457d",
      "type": "ms.vss-distributed-task.task",
      "targets": [
      "properties": {
        "name": "rootfoldername"

Deleting a task or a version

I wouldn’t recommend you trying this but it seems to have no effect on accounts having already your extension installed, and this, to avoid any disruption of service I guess. However, beware that removing an extension from the marketplace seems to be one step too far as existing account’s build/release definitions will be broken if using tasks from your extension.

In case of a mere task/version deletion, new accounts will only see the remaining tasks and/or versions while existing accounts would only get a fresh copy by uninstalling and reinstalling completely the extension which is unlikely to happen. It could be handy at tenant level to have an upgrade version as well to opt-in explicitly and have a better control over what the supplier is doing. Today, the only two options are “Disable” and “Uninstall”.

Updating the extension itself

The only way to push changes to existing and new accounts is to publish a new version of the extension itself. This can be easily done by updating the extension manifest manually and by calling tfx extension create, or simply by calling tfx extension create –rev-version which will create the extension package and change the manifest in order to increment the version number. Once the package is produced, you can simply use the update menu option:


Happy VSTS.


Posted in vsts | Tagged , , , , , | Leave a comment

DevOps – Azure API Management and VSTS, better together


Visual Studio Team Services aka VSTS is a great tool when it comes to Application Lifecycle Management, Continuous Integration and Continuous Deployment. It is a must have tool in any DevOps organization working with Microsoft technologies (but not only). With that in mind, it is a surprise to no-one that most of the Azure PaaS services are natively integrated with VSTS, using either existing extensions, either ARM templates, either ARM APIs.

However, strangely enough, I couldn’t find a real integration with Azure API Management other than this extension, which is a nice effort but not reflecting the real value of Azure API Management. Some getting started ARM templates are available but that’s rather light for now. Moreover, while ARM templates are great, they are sometimes limited or not that easy to manipulate.

So, in an attempt to contribute, I released a free VSTS extension on the marketplace, called API Management Suite,  that covers a rather broad set of features of Azure API Management. The extension helps dealing with:

  • Creation/Update of Gateway APIs with and without versioning pointing to traditional backend API services
  • Creation/Update of Gateway APIs with and without versioning on top of Azure Functions
  • Creation/Update of Gateway Products
  • Built-in support of Gateway Policies for both products & APIs

Everything is open sourced on GitHub in this repo.

Happy deployments!

Posted in Azure, DevOps | Tagged , , , | Leave a comment

May Azure AD V1.0 endpoint be used for GDPR compliancy?


By now, everybody should have heard about GDPR. While not being a lawyer, I think I can summarize it this way: any identifiable personal information as well as sensitive personal information is subject to GDPR regulation.  This first and foremost implies informing the user about which usage is done with his personal data.

The major asset to comply with GDPR is the consent. By letting users consent about what is done with their personal information, you should be on the safe path. However, GPDR comes with strong requirements such as: every distinctive usage should come with its own consent and could be revoked at any time by the end user, which means that you cannot simply bundle everything in one basket and ask the user to consent to the whole thing, even if doing this, is already better than nothing. Continue reading

Posted in Azure, Azure Active Directory | Tagged , , | Leave a comment