DEV Community: Igor Bertnyk

Docusaurus authentication with Entra ID and MSAL

Igor Bertnyk — Wed, 02 Oct 2024 16:10:23 +0000

Introduction

Docusaurus (https://docusaurus.io) is a well-regarded open-source tool for building documentation websites. It is a static-site generator that builds a single-page application leveraging the full power of React. However, it does not provide any kind of authentication out of the box. Adding authentication is crucial for securing access to your documentation.

Adding Entra ID Authentication

Let’s try to add Entra ID authentication to the static website generated by Docusaurus. In its heart, it is still a React application, so we could use relevant react packages to help with this task. However, there are some Docusaurus-specific techniques that are described below. With that in mind, let’s start!

Registering a Single Page Application

First, you will need to register a Single Page Application in Entra ID (previously known as Azure AD, Microsoft marketing department strikes again). The process is well-known and you can find step-by-step instructions there:

Single-page application: App registration

It is recommended to use MSAL.js 2.0 with auth code flow for enhanced security. Do not forget to add redirect URLs, and add http://localhost:3000/ for local debugging.

Installing MSAL Libraries

Next, install MSAL libraries for React

npm install react react-dom 
npm install @azure/msal-react @azure/msal-browser

Configuring Entra ID Registration Details

In the root of the application add authConfig.js file where you configure your Entra ID registration details.

AuthConfig.js Content

import { LogLevel } from "@azure/msal-browser";

/**
 * Configuration object to be passed to MSAL instance on creation. 
 * For a full list of MSAL.js configuration parameters, visit:
 * https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-browser/docs/configuration.md 
 */

export const msalConfig = {
    auth: {
        clientId: "YOUR CLIENT ID",
        authority: "https://login.microsoftonline.com/YOUR_TENANT_ID",
        redirectUri: "http://localhost:3000",
        postLogoutRedirectUri: '/',
    },
    cache: {
        cacheLocation: "sessionStorage", // This configures where your cache will be stored
        storeAuthStateInCookie: false, // Set this to "true" if you are having issues on IE11 or Edge
    },
    system: {   
        loggerOptions: {    
            loggerCallback: (level, message, containsPii) => {  
                if (containsPii) {      
                    return;     
                }       
                switch (level) {
                    case LogLevel.Error:
                        console.error(message);
                        return;
                    case LogLevel.Info:
                        console.info(message);
                        return;
                    case LogLevel.Verbose:
                        console.debug(message);
                        return;
                    case LogLevel.Warning:
                        console.warn(message);
                        return;
                    default:
                        return;
                }   
            }   
        }   
    }
};

/**
 * Scopes you add here will be prompted for user consent during sign-in.
 * By default, MSAL.js will add OIDC scopes (openid, profile, email) to any login request.
 */
export const loginRequest = {
    scopes: []
};

Adding Login Functionality

Finally, we need to add the actual login functionality. That is where things become more interesting. On a first look, there is no place where we can insert a custom login component and enforce authentication. However, the Docusaurus uses a technique called swizzling.

For Docusaurus, component swizzling means providing an alternative component that takes precedence over the component provided by the theme. You can think of it as Monkey Patching for React components, enabling you to override the default implementation. We need to find and override the very top component in the hierarchical tree, and Docusaurus provides just that:

Swizzling Wrapping your site with <Root> component

The <Root> component is rendered at the very top of the React tree, above the theme <Layout>, and never unmounts. It is the perfect place to add stateful logic that should not be re-initialized across navigations, such as user authentication status. Swizzle it manually by creating a file at src/theme/Root.js. The code is provided below.

import React, { useState } from 'react';

import { PublicClientApplication, EventType } from '@azure/msal-browser';
import { MsalProvider, AuthenticatedTemplate, useMsal, UnauthenticatedTemplate } from "@azure/msal-react";
import { msalConfig } from '@site/authConfig';

/**
 * MSAL should be instantiated outside of the component tree to prevent it from being re-instantiated on re-renders.
 */
const msalInstance = new PublicClientApplication(msalConfig);

// Default to using the first account if no account is active on page load
if (!msalInstance.getActiveAccount() && msalInstance.getAllAccounts().length > 0) {
    // Account selection logic is app dependent. Adjust as needed for different use cases.
    msalInstance.setActiveAccount(msalInstance.getActiveAccount()[0]);
}

// Listen for sign-in event and set active account
msalInstance.addEventCallback((event) => {
    if (event.eventType === EventType.LOGIN_SUCCESS && event.payload.account) {
        const account = event.payload.account;
        msalInstance.setActiveAccount(account);
    }
});

// Default implementation, that you can customize
export default function Root({children}) {
    const activeAccount = msalInstance.getActiveAccount();
    const claims = activeAccount ? activeAccount.idTokenClaims : null;

    const handleRedirect = () => {
        //instance.loginRedirect()
        msalInstance.loginPopup({
                ...msalConfig,
                prompt: 'create',
            })
            .catch((error) => console.log(error));
    };

    return (
        <MsalProvider instance={msalInstance}>            
            <AuthenticatedTemplate>
                <>{children}</>
            </AuthenticatedTemplate>
            <UnauthenticatedTemplate>
                <div style={{margin:'auto'}}>
                    <button onClick={handleRedirect}>
                        Sign in
                    </button>
                </div>
            </UnauthenticatedTemplate>
        </MsalProvider>
    );
}

Code Implementation

Let’s step into the code.

MSAL React instance should be instantiated outside of the component tree to prevent it from being re-instantiated on re-renders.

You can listen to authentication events and set an active account or do other actions depending on event type.

From the active account you can retrieve token claims that you can use further for role-based access control if desired.

MSAL supports two types of authentication interfaces: redirect (loginRedirect) and popup (loginPopup). In the end, the result is the same.

Use MsalProvider component with MSAL instance and AuthenticatedTemplate to display/hide content depending on user authentication status. “<>{children}</>” will render the Docusaurus-generated site.

Conclusion

And just like that, we added an Entra ID authentication to our documentation site. This setup enhances security and provides a seamless user experience.
Everyone loves Docusaurus!

Azure Container Apps - the future of K8s in the cloud?

Igor Bertnyk — Wed, 17 Nov 2021 19:23:21 +0000

At Ignite-2021 conference, Microsoft announced the preview launch of Azure Container Apps, a new fully managed serverless container service.
Azure Container Apps (ACA) provide a serverless hosting service that sits on top of an AKS service, allowing you to deploy multiple containers without dealing with the underlying infrastructure.

Let see a current Kubernetes landscape in Azure:

Service	Azure Container Apps	Azure Kubernetes Service (AKS)	Azure Container Instances	Web App for Containers
Sample usage	Build and deploy modern apps and microservices	Deploy and scale containers on managed Kubernetes	Launch containers with hypervisor isolation	Run containerized web apps
Autoscale	Yes (KEDA)	Yes (config)	No	Yes (App Service plan)
HTTPS ingress	Yes (Envoy)	Yes(may need additional infrastructure)	Yes	Yes
Split traffic	Yes	Manual	No	Yes (deployment slots)
Dapr	Yes	Manual	No	No
Long-running jobs	Yes	Yes	No	No

What new service brings to the table?

Kubernetes is hard. It is true even in managed K8s environments like AKS and Google Kubernetes Engine (GKE). It is true for newcomers or developers who want to focus on solving business requirements instead of tackling and mastering the underlying application platform.
ACA offers worry-free deployment and auto-management of many aspects of the containerized applications including service discovery and traffic splitting, support of long running processes, open-source technologies like Dapr, KEDA, and Envoy, It is optimized for running applications that span many microservices deployed in containers.

Azure Portal

Azure Portal at the moment looks pretty bare. You can create ACA, configure monitoring, secrets and view revisions but auto-scaling and other details are managed via configurations.
Currently, the maximum available container size is 2 cores / 4 GiB of memory (while other services support up to 16 GiB)

You can also configure internal or external ingress:

Microservices

Multiple ACA can be deployed into a single environment. You can think of environments as similar to Kubernetes Pods.
By doing so, they will be put under the same virtual network and isolated from the outside world. Each environment also has its own Log Analytics workspace to provide monitoring.

When you deploy your container app a new revision is created. A revision is an immutable snapshot of a container app. Revisions allow you to have the old and new versions running simultaneously and use the traffic splitting functionality to direct traffic to old or new versions of the application.

Dapr

Dapr (Distributed Application Runtime) is a runtime that helps build resilient, stateless, and stateful microservices.
Azure Container Apps offers a fully managed version of the Dapr APIs when building microservices. When you use Dapr in Azure Container Apps, you can enable sidecars to run next to your microservices that provide a rich set of capabilities. Available Dapr APIs include Service to Service calls, Pub/Sub, Event Bindings, State Stores, and Actors.

There is an excellent example created by Jeff Hollan showing how
multi-container communication can use direct calls as well as be proxied by Dapr. Dapr can provide mTLS, auto-retries, and additional telemetry.
This example also shows how to deploy the app using GitHub Actions and Azure BICEP.

Google Cloud

GCP's similar technology, GKE Autopilot mode is intended to be a hands-off fully managed Kubernetes experience that allows users to focus more on the workloads and less on managing cluster infrastructure. The difference is that Azure team chose a very opinionated route, supporting selected open-source technologies at the expense of choice.

Conclusion

Azure Container Apps is a perfect addition to Azure's container landscape. By using this ACA, you don't spend time managing Kubernetes clusters and can focus on building and deploying your application.
The biggest pros for Container Apps are the serverless container orchestration, ability to scale to 0, and usage-based pricing. Autoscaling, HTTPS ingress and Dapr take away major headaches of running your application on Kubernetes.
The possible downside is that when deploying to ACA, you are buying the way the MS built this service such as using Dapr for service mesh, KEDA for scaling, Envoy for ingress and Log Analytics for monitoring. The deployment is also performed using Azure tools so you may not bring in your beloved Helm charts. And, as of now, Windows containers are not supported.
However teams facing a modernization and planning their move to Azure Kubernetes Service may be very interested in Azure Container Apps due to simplicity and abstraction of the complex Kubernetes system.
Thanks for reading, here is a containerized cat for you, a next step in containerization :)

The ultimate guide to hosting multilingual Angular application on Google App Engine

Igor Bertnyk — Thu, 26 Aug 2021 22:56:18 +0000

Google App Engine is a good option to serve SPA applications, such as Angular. It requires little maintenance, can be easily auto-scaled if necessary, and you can extend it with CDN or load balancer. However, an Angular application requires several tricks to make it work properly. For example, to support deep links and browser refresh, routed apps must fallback to index.html. But navigation to the index page should happen only for routes, not for existing files and assets, so there should be exception for such things.
For localized, multilingual application that becomes even more complicated. Let's see why.
Internationalization (aka i18n) of the applications is often mandated for countries other than USA, and useful even there, if you want to make them accessible world-wide. To localize my app I have followed the official guide:
Localizing your Angular app
This is a fairly involved process that I will not describe here. Sufficient to say that after all preparations, translation of the resource files and changing of the build process, in your "dist" folder you will get a copy of your application for every language supported. So, for example, if you support English and French, in the "dist' folder there will be "en" and "fr" subfolders, each containing a full translated application.
In a typical multilingual application navigation to the different language is facilitated by URL prefix, e.g. "https://myapp.com/fr/login" will show the login page in French, so we need to map these URL patterns to the underlying application assets.
Let's quickly go through the build and deployment process and then we will see how to do that mapping.

As I mentioned, the build process is slightly changed:

npm run build -- --configuration=production --localize

To deploy to Google Cloud you need "gcloud CLI". If you are using CI/CD pipelines, it is often preinstalled on all major DevOps platforms and agents.
You'd need to authorize the CLI session, either manually, or with the help of the secret credentials file, which you can download from the GCP console (navigate to APIs & Services/Credentials).
This is a sample command:

gcloud auth activate-service-account --key-file=$(gcloud.secureFilePath)

Finally, to deploy your app to the App Engine, you can execute the following command:

gcloud app deploy --verbosity=info <path to your dist folder>/app.yaml --promote --stop-previous-version --quiet --project=<your GCP project ID>

Replace the values in angle brackets accordingly.

Now we get to the most important part: how to make our Angular app work on App Engine.
The magic resides in the "app.yaml" file, with the help of which we can overcome all of the obstacles I listed above.
The full reference can be found here, but for Angular we need just a subset of configuration options.
Several points to mention before I attach the full app.yaml file for your reference.

Remember that app.yaml should be in the root (dist) folder.
Python instance in Standard Environment is the simplest hosting option to set up.
Affinity is not required, as Angular package will be downloaded to the client, and sessions will be facilitated by the browser.
Downloaded javascript packages will be often cached on a client side, so usually we should not expect an extremely high load on our server.
We need to provide a fallback for all routes to the index.html page in the corresponding language.
Images, fonts, and other static assets should be exempted from the above rule.
It might be a good option to have a "landing page" from which the user can navigate to the language of choice, or it can automatically redirect the user based on the browser language settings.

And behold! A sample app.yaml file that you can freely reuse to host you Angular application on App Engine:

I hope that was helpful. Any comments on how to make this config even better are welcome. Here is a multilingual, French-speaking cat for you:

^{(Saved from etsy.com)}

Google Secret Manager Configuration Provider for ASP.NET Core

Igor Bertnyk — Wed, 18 Aug 2021 21:12:51 +0000

If you are brave enough to run ASP.NET Core applications on Google Cloud Platform, sooner or later you will encounter a question on how to store your application settings in a secure way. In Azure we have Key Vault for that purpose, which is nicely integrated with ASP.NET Core thanks to the built-in Configuration Provider. In GCP, the corresponding service is called Google Secret Manager.
Secret Manager is a secure and convenient storage system for API keys, passwords, certificates, and other sensitive data, and certainly is a good place to store application settings as well. However there is no integration with ASP.NET Core out of the box.
Fear not! ASP.NET Core supports Custom configuration providers, and we will try to develop one for the Google Secret Manager now.

SecretManagerConfigurationSource

First of all, we need to create a class that implements IConfigurationSource. The only purpose of which is to return an instance of our custom provider, which we develop shortly.



public class SecretManagerConfigurationSource : IConfigurationSource
    {
        public IConfigurationProvider Build(IConfigurationBuilder builder)
        {
            return new SecretManagerConfigurationProvider();
        }
    }

SecretManagerConfigurationProvider

Next, let's start creating our main component, SecretManagerConfigurationProvider, which needs to inherit from the ConfigurationProvider abstract class:



public class SecretManagerConfigurationProvider : ConfigurationProvider

To retrieve secrets from the Secret Manager, we can use SecretManagerServiceClient from Google.Cloud.SecretManager.V1 Nuget package. We will also need a Google Project ID where the Secret Manager is enabled and your application is running.

How can we get a Project ID? We can, for example, put it into applications settings. But in fact, we can get it easily at runtime using Google API:



public static string GetProjectId()
{
    var instance = Google.Api.Gax.Platform.Instance();
    var projectId = instance?.ProjectId;
    if (string.IsNullOrEmpty(projectId))
    {
        return null;
    }
    return projectId;
}

Returning to our Configuration Provider, we are ready to initialize it in the constructor:



public SecretManagerConfigurationProvider()
{
    _client = SecretManagerServiceClient.Create();
    _projectId = GoogleProject.GetProjectId();
}

The next step is to overload the "Load" method and populate a Dictionary of key/value pairs that is exposed as Data property in the parent class.



var secrets = _client.ListSecrets(new ProjectName(_projectId));
foreach (var secret in secrets)
{
   var secretVersionName = new SecretVersionName(secret.SecretName.ProjectId, secret.SecretName.SecretId, "latest");
   var secretVersion = _client.AccessSecretVersion(secretVersionName);
   Set(secret.SecretName.SecretId, secretVersion.Payload.Data.ToStringUtf8());
}

SecretManagerConfigurationExtensions

Finally, let's add a convenience extension method to easily add our new configuration provider to the ASP.NET Core application.



public static IConfigurationBuilder AddGoogleSecretsManager(this IConfigurationBuilder configurationBuilder)
{
    configurationBuilder.Add(new SecretManagerConfigurationSource());

    return configurationBuilder;
}

Typically, you'd use this method in Program.cs file:



public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
        .ConfigureAppConfiguration((_, config) => config.AddGoogleSecretsManager())
        .ConfigureWebHostDefaults(webBuilder => webBuilder.UseStartup<Startup>());

The full source code of Google Secret Manager Configuration Provider, with more error handling, comments, and tests can be found in this Github repo:

i-b1 / GoogleSecretManagerConfigurationProvider

Google Secret Manager Configuration Provider

More than that, you can download a IB.Google.SecretManager.ConfigurationProvider NuGet package and use freely in your projects

And that is essentially everything that was needed to implement a custom configuration provider. Now you can start using Google Secret Manager to store your applications settings in a more secure way, simplify your CD pipelines by removing those variables from different stages, and stop worrying about those pesky cat hackers.

^{(Image credit: iridi/Getty Images)}

A brief history of application architecture (of the 21st century)

Igor Bertnyk — Tue, 22 Jun 2021 18:06:44 +0000

N-Tier Architecture
Ports & Adapters
Onion Architecture
CQRS
Beyond

N-Tier Architecture

Admittedly created long before year 2000, this type of architecture became popular in web applications around that time.

Tiers and Layers

Layers are a way to separate responsibilities and manage dependencies. Each layer has a specific responsibility. A higher layer can use services in a lower layer, but not the other way around.
Tiers are physically separated, running on separate machines. A tier can call to another tier directly, or use asynchronous messaging (message queue).

Typical app consist of 3 layers:
Presentation Layer holds the Part that the User can interact with, e.g. WebApi.
Business Logic holds all the logics related to the business requirements.
Data Access Layer usually holds ORMs to access the Database

More complex implementation

It is not restricted to 3 tiers. A tier can call to another tier directly, or use asynchronous messaging (message queue).
Although each layer might be hosted in its own tier, that's not required. Several layers might be hosted on the same tier.

Benefits and Disadvantages

When to use

Simple web applications.
Migrating an on-premises application to Azure with minimal refactoring.
Unified development of on-premises and cloud applications.

Challenges

It's easy to end up with a middle tier that just does CRUD operations on the database, adding extra latency without doing any useful work.
Monolithic design prevents independent deployment of features.
Makes it difficult for developers to change an application and for operations teams to scale the application up and down to match demand.
The Database is usually the Core of the Entire Application, i.e. it is the only layer that doesn’t have to depend on anything else. Like in Jenga tower, any small change in the Business Logics layer or Data access layer may prove dangerous to the integrity of the entire application.

Ports & Adapters

History

Ports and Adapters or also known as Hexagonal Architecture, is a popular architecture invented by Alistair Cockburn in 2005.
"Allow an application to equally be driven by users, programs, automated test or batch scripts, and to be developed and tested in isolation from its eventual run-time devices and databases."
This is one of the many forms of DDD (Domain Driven Design Architecture)

Motivation

The idea of Ports and Adapters is that the application is central to your system. All the inputs and outputs reach or leave the core of the application through a port. This port isolates the application from external technologies, tools and delivery mechanics.

Benefits

Using this port/adapter design, with our application in the centre of the system, allows us to keep the application isolated from the implementation details like ephemeral technologies, tools and delivery mechanisms, making it easier and faster to test and to replace implementations.

Components

Core A place where the business logic of the application happens
Ports Ports represent the boundaries of the application (usually interfaces)
Inbound ports communication points between the outside and the application core
Outbound Ports This are the interfaces the core need to communicate with the outside world
Adapter Implementation of ports

Onion Architecture

he Onion Architecture was introduced by Jeffrey Palermo in 2008:
https://jeffreypalermo.com/2008/07/the-onion-architecture-part-1/
This is an evolution of Ports & Adapters Architecture.

The idea of the Onion Architecture is to place the Domain and Services Layers at the center of your application, and externalize the Presentation and Infrastructure.

Layers (rings) : Core

Core Domain and Application Layer form the core of the application. These layers do not depend on any other layers
Domain Model This is the center of the architecture. It contains all the domain entities. These domain entities don’t have any type of dependencies
Domain Services responsible to define the necessary interfaces to allow to store and retrieve objects.
Application Services This layer has the purpose to open the door to the core of the onion. The Service layer also could hold business logic for an entity. In this layer, service interfaces are kept separate from its implementation, keeping loose coupling and separation of concerns in mind. The Core Layers should never depend on any other layer.

Outer Layers

UI / Test Layer It's the outermost layer, and keeps peripheral concerns like UI and tests. For a Web application, it represents the Web API or Unit Test project
Infrastructure This ring has an implementation for the dependency injection principle because the architecture contains the core interfaces in the center and their implementations are at the edges of the application services ring. Infrastructure can be anything: Entity Framework Core Layer to access DB, Email Notification sender, Messaging System etc.

Benefits and Drawbacks

Benefits

Onion Architecture layers are connected through interfaces. Implementations are provided during run time.
Application architecture is built on top of a domain model.
All external dependency, like database access and service calls, are represented in external layers.
No dependencies of the Internal layer with external layers.
Couplings are towards the center.
Flexible and sustainable and portable architecture.
Can be quickly tested because the application core does not depend on anything. Cons
Not easy to understand for beginners
Sometimes it is not clear how to split responsibilities between layers

Command Query Responsibility Segregation (CQRS)

Context and problem

In traditional architectures, the same data model is used to query and update a database. That’s simple and works well for basic CRUD operations. In more complex applications, however, this approach can become unwieldy. For example, on the read side, the application may perform many different queries, returning data transfer objects (DTOs) with different shapes. Object mapping can become complicated. On the write side, the model may implement complex validation and business logic. As a result, you can end up with an overly complex model that does too much.
Read and write workloads are often asymmetrical, with very different performance and scale requirements.
There is often a mismatch between the read and write representations of the data, such as additional columns or properties.

Solution

CQRS addresses separate reads and writes into separate models, using commands to update data, and queries to read data.
Commands should be task-based, rather than data-centric. (“Book hotel room,” not “set ReservationStatus to Reserved.”) Commands may be placed on a queue for asynchronous processing, rather than being processed synchronously.
Queries never modify the database. A query returns a DTO that does not encapsulate any domain knowledge.

Typical	CQRS

^{https://docs.microsoft.com/en-us/azure/architecture/patterns/cqrs}

MediatR

MediatR is an open source implementation of the mediator pattern. It allows you to compose messages, create and listen for events using synchronous or asynchronous patterns.

See how CQRS implementation with MediatR in ASP.NET Core allows to significantly simplify Controller's code.
Before



[HttpPost]
public async Task<IHttpActionResult> Register (RegisterBindingModel model) {
   var user = new User {
       UserName = model.Email,
       Email = model.Email,
       DateOfBirth = DateTime.Parse (model.DateOfBirth.ToString (CultureInfo.InvariantCulture)),
       PhoneNumber = model.PhoneNumber,
       Name = model.Name
   };
   var result = await UserManager.CreateAsync (user, model.Password);
   if (!result.Succeeded) return GetErrorResult (result);
   return Ok (result);
}

After



[HttpPost]
public async Task<IHttpActionResult> Register ([FromBody] CreateUserCommand command) {
   return Ok (await Mediator.Send (command));
}

The source of the demo can be downloaded from https://github.com/i-b1/OnionArchitectureDemo

Next Steps

Event Sourcing

https://docs.microsoft.com/en-us/azure/architecture/patterns/event-sourcing

Designing Microservices:

https://docs.microsoft.com/en-us/dotnet/architecture/microservices/

Thank you for reading, next step would be to consider how Onion stacks up against CATs (Cloud Application Technologies???) and microservices.

^{Photo by HalGatewood.com on Unsplash}

How to pass Google Cloud Architect Certification exam

Igor Bertnyk — Wed, 15 Jul 2020 19:07:16 +0000

There are multiple articles out there about Google Cloud Professional Architect Certification, so I'll just describe my personal experience and impressions from this exam and my preparations to passing this certification.

GCP Architect Exam

On the outside, this exam is a typical multiple-choice test, with some questions having more than one answer. There is no lab environment where you need to perform some actions, like some other providers like Cloudera and Microsoft started to incorporate into their tests. The test has 50 questions and you get 2 hours to complete them.
The biggest difficulty is that many questions revolve around three case studies which represent fictitious scenarios for companies migration to the GCP. The intent, I think, is to evaluate how you professionally perform in the Cloud Architect role, rather than around the Google Cloud platform itself. That makes you balance between functional and non-functional requirements and consider cost, existing infrastructure and processes, regional vs global representation, scalability and latency, among others. The answers could be different depending on what is emphasized in the particular question.
I guess the most peculiar thing about the exam is that it does not provide any feedback, so it is difficult to judge which areas need improvement.
Previously, you could only take this exam in one of the test centers but now it is available online too, "thanks" to the COVID-19 situation in the world. Many test centers started to open now though, so you can choose what is most suitable to you. I have to warn though that if you are taking it from home there are some requirements to your home environment, webcam, and computer that you need to check, and the dedicated proctor is going to watch over you during the exam. Logistically, it is simpler to get it from the test center.

Exam preparation

Coursera's Preparing for the Google Cloud Professional Cloud Architect Exam gives a good overview of the certification and provides some good points for your preparation. It is also free. This course is a part of a larger "Cloud Architecture with Google Cloud Professional Certificate" program, however I found it too bloated and there are better paid options from other learning providers.
The one that I liked is Google Cloud Certified Professional Cloud Architect by Matthew Ulasien. It is just over 30 hours long and includes access to 15 labs that will help to cement your knowledge of the GCP. There is also a sample test you could try multiple times with different questions, and a Lucidchart multi-page diagram to help you navigate the lessons and GCP resources. Overall, this course provides an excellent value for the money.
Speaking of labs, Qwiklabs has a vast catalog of hands-on labs on almost all aspects of GCP and this resource is invaluable if you want to dive into more practical usage of the Google Cloud platform.
Finally, I found that the Professional Cloud Architect – Google Cloud Certification Guide book is very well structured and, despite several insignificant errors, provides complete information necessary to pass the exam and will help to fill the gaps in online lessons.
Pay special attention to VMs, images and managed instance groups, storage options, Kubernetes gcloud and kubectl commands, networking options and connection to on-premises data and, of course, case studies.

In conclusion

A word of encouragement to all candidates: do not be afraid, the exam is not as difficult as it seems, and with about 2 months of studying, following the guide above, it is possible to prepare for the test. Of course, practical experience would help immensely, and I recommend to get a GCP free-tier to explore it in detail, as well as going through the related Qwick Labs.
Lastly, don’t forget to take the practice exam!

This is my certificate and I wish all the best to everyone preparing for this exam. Don't worry, here is a cat for you:

Azure DevOps Multi-Stage YAML Pipelines for Google Firebase Functions

Igor Bertnyk — Mon, 15 Jun 2020 20:29:31 +0000

In one of my previous posts I've discussed how to deploy Google Cloud functions using Azure Pipelines. However many of the developers are using Firebase Functions, which are the same Google Cloud Functions in disguise, but deployed using Firebase CLI. I'd like to see how we can do it in the context of Azure DevOps. But this time let's make it closer to reality.
Usually we'd have many environments: Development, Staging, Production, and deployment to each one is governed by multiple rules. UAT tests need to be passed, various approvals received etc. In Azure DevOps this problem is solved using "stages". For a long time "classic" Release Pipelines supported stages that could target deployments to different environments. A fairly new feature is multi-stage YAML pipelines. I wanted to evaluate this feature from several standpoints: whether it supports approvals for stages, can I see where the current build is deployed, can I re-deploy a previous build, and if unit and coverage tests results can be displayed.
With that in mind, let's build a multi-stage pipeline to deploy a Node.js-based Firebase function to GCP.

Deploying Firebase functions

In comparison to pure Google Cloud Functions deploying Firebase is a breeze. We only need to install firebase-tools NPM package globally and issue one command, is you'd see below in the pipeline source. The only things we need to have is a GCP project name and a Firebase authentication token.

Firebase Token

This command generates a token that can be used in CI/CD pipelines:


 login:ci

With that information we are ready to move to the Azure DevOps.

Azure Multi-Stage Pipeline

Here is the full pipeline source and then we can discuss different parts of it.

As you could see, the pipeline hierarchy is Stage/Job/Steps/Task.
The first stage is building, testing the project, and producing a deployment artifact. There is not much interesting here other than that stage represents a typical Continuous Integration pipeline in its entirety. Next stages correspond to the Continuous Deployment part.
Here some things are becoming more exciting. We can see that the "deployment job" can have several additional parameters, such as

environment name - corresponds to the names on the "Environments" page. We'll talk about it later in the "Approvals" section.
strategy - e.g. runOnce or matrix are useful in single- or multi-platform deployments. For every environment we could create a separate stage and provide different variables and deployment options. One of the first steps to do is to download an artifact that was published by the "build" stage. In that way we can ensure that each of the deployment stages uses exactly the same build package.

Variables

Very often we don't want to hard-code environment-specific parameters in your pipeline. That is where variables come to play.
Variables can be specified in several ways. One of them is "pipeline" variables. When editing the pipeline there is a "Variables" tab as you could see on a screenshot below, where you could add and edit the variables. In the pipeline you could refer to them via special syntaxis, for example as $(firebase-project)

Another way is specifying variables in the "Variables Groups" on the "Library" page. The advantage of this method is that we can secure the access to different groups, so, for example, developers would not be able to see the Production variables.

Tackling Approvals

While in "Classic" Release pipelines we are able to add approvals to the stage itself, for YAML pipelines they are handled via the "Environments" page.

We can add approvers and set a minimum number of approvers here.

Viewing deployments

On the pipeline page we could visually see how many stages were successfully executed, as well as view test results and generated artifacts

Final words

In this post we were able to use new YAML-based multi-stage pipelines to produce a combined CI/CD pipeline for Google Firebase functions deployment. We achieved all of the goals:

unit testing
test results
reproducible builds
environment-specific variables
deployment approvals
viewing where the build is deployed

However YAML pipelines still do not have a parity with the "classic" release pipelines. For example, the pipeline is stuck in "Pending" status until a final stage is approved and deployed, which feels awkward and leads to ridiculous build time displayed - one/two, or more days. Also, at a glance, we can only see which stages were completed, but we need to drill down to view the environment.
Hopefully, the multi-stage pipelines will grow and mature as the cat on the image below did.

Protecting Azure Functions with API Management Service

Igor Bertnyk — Tue, 12 May 2020 03:31:45 +0000

Cloud functions are great. Who does not like automatic scalability and hands-off infrastructure management? HTTP-triggered Azure functions however are exposed to the public Internet. So if we want to use them, for example, as a part of a microservice-based application, we'd want to take steps to secure those functions from malicious attacks.
One way would be to bake authentication and authorization into the function itself. However this does not prevent public access to the HTTP endpoint. And even though the function would be secured, Azure will still charge for the execution, making it a target of "denial-of-wallet" attack.
I wish that there was an option to create a function in something like Google Cloud Virtual Private Network, or even Azure's own VNet, exposing only internal IPs by default. Well, you can use a dedicated Azure App Service Environment (ASE), but the pricing makes it prohibitive, and it greatly reduces the flexibility.
One of the solutions, as it often is in software engineering, is to insert another level of indirection. Azure API Management Service can help to secure your APIs.
In a high-level view, as seen in a cover image, APIM will stand between the client and the function endpoint, managing authentication and access, while the function will be protected by the Azure Active Directory. In addition, API Management comes with a vast number of features, like limiting quotas, API documentation, integration with payment service and many others, which is impossible to fit into one article. And that is, anyway, not what the title says.
Let's get to the subject and do step-by-step configuration of the API Management and Azure Function, as there are several tricky steps that better not to be skipped.

Enable APIM Managed Identity

The first thing that we need to do is to enable APIM Managed Identity. Well, the first thing is to create an instance of the API Management Service, but it could be easily provisioned in Azure Portal Beware though that it takes up to an hour to get it. This and consequent steps we will be doing in the Azure Portal. Navigate to your APIM instance, select the "Managed Identity" menu, and enable the checkbox.

Secure Azure Functions with Azure Active Directory

Having finished the first step, let go to the Azure Function you want to secure. (You've already created one, right?). We can safely disable existing levels of protection, like Function Keys, and make a function anonymous. Now we need to integrate it with Azure AD. For that, click on (1) "Authentication/Authorization" link in Platform Features tab. It will open a new page. We will return to the previous one and use a link number (2) "API Management" when we finish with Active Directory steps.

Enable App Service Authentication and select "Log in using AAD" from the dropdown.

Let's choose the "Express" setting to create a new Active Directory app. Give it a name, and remember it, as we'll need it in the next step.

Finding AAD Application ID

Once an Azure AD application is created, we need to find its Application ID.
In the top search bar, search for "Azure Active Directory", and select "Enterprise Applications" from the left menu. Now look up your newly created AD app (you can use a filter to type the name), and copy the Application ID.

Importing API to Azure Management Service

We are done with Active Directory. At this point you can check that your Function is not callable from the direct URL anymore, and you should get an Unauthorized response. Now we need to expose your function again and the easiest way to do that is from Function's Platform Features page (a link #2 "API Management" from the image above we promised to return to).
Select an existing instance of APIM, "Create New API", and click on "Link API" button. It will import your functions endpoints to the APIm, and you'll be redirected to the corresponding APIM page.

Applying Inbound Policy to the API

Finally we are approaching one of the most important steps - applying inbound policy for the API that we imported from the Azure function.
To be able to successfully call a function via API Management, an inbound policy rule should insert authorization token (APIM Managed Identity) and be able to verify it using our Active Directory App.
To modify an inbound policy select the API and click on Policies "</>" link. It will open an XML Editor. Insert the lines below after the "base" policy. Replace [Azure AD Application ID] with the values we found earlier, and save.

  <authentication-managed-identity resource="[Paste Azure AD Application ID]" ignore-error="false" />
  <set-header name="Ocp-Apim-Subscription-Key" exists-action="delete" />

Checking Azure Active Directory Integration

Let's test our integration. We can do it right in the APIM console.
Select one API endpoint and go to the Test tab. Here we can enter parameters, if they are required for your function and click Test. After that we will get a (hopefully) successful result. But if not, click on a Trace tab and ensure that you see "Managed Identity token is added to the Authorization header" message.

We are done! Or are we? Our function direct URL is secured, but we now exposed it via API Management URL, and it is publicly accessible again. The thing is, now APIM gives you flexibility to apply an authentication method of your choice, being it Subscription Keys, JWT tokens, OAuth 2.0, OpenID Connect, or integration with third-party providers like Okta or Auth0. But that is a different story and possibly a subject for another post.
One hint though: remember that policies are evaluated in order. So, for example, if you decide to authenticate your API with JWT Tokens, a "validate-jwt" policy should come before the "authentication-managed-identity" policy that we implemented here. Otherwise an "Authorization" header will be replaced before having a chance to be validated.

Final thoughts

In this article we described a way to secure publicly accessible HTTP Azure functions with API Management Service and Azure Active Directory. Now you can relax and manage your API with style, like a cat manages his money in the picture below.

^{© APTYP_KOK / GETTY IMAGES}

Azure DevOps Recipe: Deploying Google Cloud function to GCP

Igor Bertnyk — Tue, 07 Apr 2020 20:24:34 +0000

Deploying Using Google Cloud Build
Deploying Using Azure Pipelines
- Setting up Google Service Account
- Storing Security Key
- Creating CI/CD pipeline
Final thoughts

It goes without saying that Azure Devops pipelines and Azure cloud is a natural fit. A deployment to Azure is streamlined with many ready-to-use templates and Azure CLI installed by default on managed agents. However the reality is that a lot of companies have to deal with a multi-cloud environment. It would be beneficial if we can manage our builds and deployment in one place, no matter what cloud provider is used.
In this recipe we will consider the deployment options for Google cloud function on GCP and walk through detailed steps of creating CI/CD pipeline in Azure DevOps. For the purpose of this exercise we assume that you already developed a function. If not, you can use one of the many tutorials, like this one, to create one.

Using Google Cloud Build

So one way to deploy a cloud function would be to use a native Google Cloud Build. We can set up a connected external Cloud repository at https://source.cloud.google.com that will be automatically synchronized with our main repo. Then we can create a Cloud Build Trigger that can run a YAML pipeline not dissimilar to Azure's one. When a new change is pushed to the Git repo, it will be synced to the Google repository and trigger the build and deployment.
There are however several issues with that. First of all, an external repository could be hosted only on Github or Bitbucket, as seen on a screenshot below. So if your source code is in Azure Repos or anywhere else, you are out of luck.

But most importantly, it moves a control and auditing out of Azure Devops and that contradicts our goal of keeping everything under one roof.

Using Azure Pipelines

Fortunately, Azure Pipelines are flexible enough to deploy to practically any environment. We will outline basic steps to do that for Google Cloud Functions and GCP.

Setting up a Service Account

We will need a Google Service Account to secure a communication between Azure Pipelines and GCP. Taking from the Google documentation here is how to do it using Google Cloud Shell.

Login to GCP Console.
Select the project where your function is deployed.
Activate Cloud Shell.
Set default configuration values to save some typing. Replace [PROJECT_ID] and [ZONE] with appropriate values.
```
gcloud config set project [PROJECT_ID]
gcloud config set compute/zone [ZONE]
```

Create a Service Account:

gcloud iam service-accounts create azure-pipelines-publisher --display-name 
"Azure Pipelines Publisher"

Assign the Storage Admin IAM role to the service account:

PROJECT_NUMBER=$(gcloud projects describe \
$(gcloud config get-value core/project) \
--format='value(projectNumber)')

AZURE_PIPELINES_PUBLISHER=$(gcloud iam service-accounts list \
--filter="displayName:Azure Pipelines Publisher" \
--format='value(email)')

gcloud projects add-iam-policy-binding \
$(gcloud config get-value core/project) \
--member serviceAccount:$AZURE_PIPELINES_PUBLISHER \
--role roles/storage.admin

We also need to generate and download a service account key to use later on in an Azure Pipeline. The easiest way is to navigate to the IAM & Admin / Service Accounts menu, and select "Edit" on azure-pipelines-publisher@[PROJECT_ID].iam.gserviceaccount.com that we just created. Then create a key as on a screenshot below.

Keep the file as we are going to use it in a moment.

Storing service account key in Azure DevOps

We pretty much finished with Google Platform, let's switch to Azure DevOps and continue there.
To upload a JSON file go to the Library page under the Pipelines navigation panel and select the "Secure Files" tab. Here we can add our key to the library.

After the key is uploaded, edit it and toggle "Authorize for all pipelines" to be able to use it in our pipeline.

Creating CI/CD pipeline

Our simple pipeline will deploy one cloud function to GCP. Of course, it can be extended with unit tests and other functions, but we want to show the bare minimum.

First, let's use the secure key that we uploaded earlier:

- task: DownloadSecureFile@1
  name: authkey
  displayName: 'Download Service Account Key'
  inputs:
    secureFile: 'GoogleServiceAccountKey.json'
    retryCount: '2'

Next, we need a Google Cloud SDK to deploy our function.

!!!UPDATE 2020-05: Good news, on the "ubuntu-latest" hosts Google Cloud SDK (292.0.0) is installed by default. So you probably can skip this step. See this link for more details: Ubuntu1804

The biggest challenge is that Google Cloud SDK is not installed on Microsoft Hosted Agents, understandably so. There are a couple of ways to do that.
Official Google Documentation did not work for me though right out of the gate. But you can follow the link if you'd like to install it using apt-get. Alternatively, we can get the package directly from the Google download site.

- script: |
    wget https://dl.google.com/dl/cloudsdk/release/google-cloud-sdk.tar.gz
    tar zxvf google-cloud-sdk.tar.gz && ./google-cloud-sdk/install.sh --quiet --usage-reporting=false --path-update=true
    PATH="google-cloud-sdk/bin:${PATH}"
    gcloud --quiet components update
  displayName: 'install gcloud SDK'

Finally, we are ready to deploy the function:

- script:
    gcloud auth activate-service-account --key-file $(authkey.secureFilePath)
    gcloud functions deploy [FUNCTION_NAME] --runtime nodejs8 --trigger-http --region=[REGION] --project=[PROJECT_ID]
  displayName: 'deploy cloud function'

As usual, here is a full source code of the YAML pipeline:

Final thoughts

When you work in a multi-cloud environment it is especially important to consolidate DevOps operations for better control, monitoring and auditing. Azure DevOps could be one of the answers as it allows deployment to multiple platforms and integrates many aspects of software development life cycle into a cohesive, easy to use product. As an example, in this recipe we created a sample CI/CD pipeline to deploy a Google function to GCP.

I hope that was useful, here is a cat (in a cloud!) for you.

Azure DevOps Recipe: Deploying Azure Logic App using Powershell Script

Igor Bertnyk — Tue, 31 Mar 2020 17:43:12 +0000

Azure Logic Apps is a somewhat unique cloud service that allows to connect your business-critical apps and services, automating your workflows without writing a single line of code.
There are numerous articles out there about how to deploy Azure Logic App with Azure Resource Manager templates, including official Microsoft documentation:
Automate deployment for Azure Logic Apps by using Azure Resource Manager templates
But in a corporate environment this kind of resources, especially in Production environment, are predefined and secured. Developers often do not have permission to overwrite existing resources, and deploying with ARM templates does exactly that. The template defines the infrastructure, resources, parameters, and other information for provisioning and deploying your logic app. But what we need is to leave the infrastructure alone and deploy just our logic app and its parameters.
So what to do when you dealing with this kind of restricted environment but still want to leverage the power of CI/CD pipelines?
Fortunately, when you create a Logic App using Visual Studio, a sample deployment Powershell script named "Deploy-AzureResourceGroup.ps1" is created for us too. In fact, it uses Azure PowerShell extension that simplifies the management of Azure Cloud services.

Here is a beginning of this script, pay attention to the parameters that we can provide to customize it:

Param(
    [string] [Parameter(Mandatory=$true)] $ResourceGroupLocation,
    [string] $ResourceGroupName = '<YOUR RESOURCE GROUP NAME>',
    [switch] $UploadArtifacts,
    [string] $StorageAccountName,
    [string] $StorageContainerName = $ResourceGroupName.ToLowerInvariant() + '-stageartifacts',
    [string] $TemplateFile = 'LogicApp.json',
    [string] $TemplateParametersFile = 'LogicApp.parameters.json',
    [string] $ArtifactStagingDirectory = '.',
    [string] $DSCSourceFolder = 'DSC',
    [switch] $ValidateOnly
)
...

A full code for the deployment script is provided at the end of the article for those who want to use VS Code or other editor to develop a Logic App.
Let's leverage this script and create CI/CD pipelines in Azure DevOps.

Creating a build artifact in Azure DevOps pipeline

The only things that we need to create a deployable artifact are the files that are located in the project's folder: a JSON file containing the workflow, a parameters file, and a script. So a build pipeline could be extremely simple, consisting just of one step, like the one below.

- task: PublishBuildArtifacts@1
  displayName: 'Publish Artifact: LogicApp'
  inputs:
    PathtoPublish: 'src/LOGIC_APP_FOLDER'
    ArtifactName: 'LogicApp'
    publishLocation: 'Container'

Execute the build pipeline to create an artifact.

Release pipeline

We can start with an empty Release pipeline, and add an artifact produced by the Build pipeline.

Next, we add a stage, and a single Azure Powershell Task. It is very important to select a Task Version as "2.*" and, correspondingly, Azure PowerShell Version as "Specify Other Version" and Preferred Azure PowerShell Version as "2.1.0" as that is the version that the deployment script is using.

Other important parameters are Script Path - you can navigate to your artifact and select a deployment script.
Also, Script Arguments is a field where we can provide parameters to the script itself. Those arguments correspond to the parameters that we see at the beginning of the script.
A good thing about Azure Powershell task is that it will automatically authenticate it to the Azure via service connection, so you do not have to worry about that.

Powershell Script

Here is a gist with a complete script's code:

Conclusion

An alternative method to deploying Azure Logic app is to use Azure Powershell script that is relatively straightforward, does not require elevated permissions, and is applicable in the enterprise and restricted environments.

Well, that is all for this simple recipe. Good luck, and when developing your Logic App be sure not to use a cat logic!

^{Photo credit: Ryozuo}

A missing step: Backup Azure DevOps Repositories

Igor Bertnyk — Fri, 13 Mar 2020 14:36:58 +0000

Table of content

To backup or not to backup?
Method 1: Using Git
Method 2: Using Azure DevOps API
Conclusion

To backup or not to backup?

Don't get me wrong, I like Azure DevOps. There are some frustrations here and there, for example in managing permissions and caching build resources. And each of Azure DevOps modules (Dashboards/Wiki, Boards, Repos, Pipelines, Test Plans, Artifacts) might not be THE BEST on a market. But integration and ease of use make it greater than sum of the parts, especially for small and medium-size projects.
Still, there is one thing that puzzles me. Backing up your Git repositories seems to me like common sense and a good practise. It also can be a policy in some companies. However there is no way to do it now either manually or on schedule. Of course, Microsoft is committed to keep the data safe, including periodic backups and geo-replication, but we do not have any control over it. And it does not prevent from unintentional or malicious actions leading to data loss.
Microsoft's response to such requests, and I quote: "In current Azure DevOps, there is no out of the box solution to this, you could backup your projects by downloading them as zip to save it on your local and then upload it to restore them. And you also could backup your work items by open them with Excel to save in your local machine."
I mean what, LOL. Excel as a backup tool is possibly a new high in data safety. Anyway, are there ways to twist control back into our hands?
Of course there are, and today we explore two of them.

Backup repository using plain old git bash script

One of the methods is to use a bash script to get a complete copy of the repository. Let's not run it from our laptop, but rather spin up a small VM in the cloud.

Plan of attack:

Create a cheap Linux virtual machine in Azure
Generate new SSH Key Pair
Add SSH Public key to Azure DevOps
Create bash script to mirror Git Repo
Execute that script on schedule

Not diving into too much details, but it is quite easy to create a Linux VM in Azure. It already comes with everything we need: Git and shell scripts. Then we can SSH into it and create a bash script, which I named "devopsbackup.sh".
A script is rather primitive, but it gets the job done. Essentially, it deletes a previous backup and creates a mirror copy of the Git repo. Don't forget to replace variables in angle brackets with your own values.

#!/bin/bash
error_exit()
{
        echo "${PROGNAME}: ${1:-"Unknown Error"}" 1>&2
        exit 1
}
#
echo "Executing Azure DevOps Repos backup"
cd /home/devopsadmin
rm -rf repos/
mkdir -p repos
cd repos/
git clone --mirror git@ssh.dev.azure.com:v3/<organization>/<project>/<repo> || error_exit "$LINENO: "

cd ..
exit 0

Allow script execution:

chmod 0755 devopsbackup.sh

We also need to generate SSH key pair by using command

ssh-keygen -C "devopsbackup"

By default, keys will be generated in "~/.ssh" folder. We need to copy a public key "id_rsa.pub" from there and paste into Azure DevOps. Go to the profile settings on a top right and add a new key from there:

We can easily create a scheduled execution for our script. Go ahead, type "crontab -e" in the command line and add something like this to the Cron config:

20 1 * * * /home/devopsadmin/bin/devopsbackup.sh >/dev/null 2>&1

Next step could be to extend this script using Azure CLI and upload this archive into Azure Blob Storage or Data Lake.
Alternatively, Azure also has a great feature that allows you to create a daily/weekly backup for your VM. So you can just store a snapshot of the whole VM and don't bother with Blob storage, if you like.

Backup default branch using Azure Devops API

That's all well and good, but is there some more modern way that does not require a dedicated VM and shell scripts/cron? Azure DevOps REST API seems to be promising and allows to manipulate Azure DevOps data, including work items and repositories. Unfortunately this API does not have a parity with Git and full code history cannot be preserved using this method.
However if all you require is a periodic snapshot of the master branch then it could be used to create a simple backup solution. One advantage over previous solution is that we can automatically retrieve information about all our projects and repos, and do not need to hardcode them. So if you add a new project, no modification is required.

Approach:

Use REST API to retrieve hierarchy of projects, repositories, items and blobs
Use Azure DevOps token (PAT) for the API authentication
Use Azure Function with timer trigger to run this on schedule
Use Azure Blob Storage to keep an archive.

Without further ado, here is a gist for Azure Function. It requires the following parameters that you can set up in Application Settings:
"storageAccountKey", "storageName", "token", "organization"

Conclusion

Comparing these two approaches we can see that newer is not always better. With a help of a simple shell script we can produce a full copy of the repository that could be easily restored or imported into the new project. On the other side, if all you want is a periodic repo snapshot, Azure DevOps REST API and scheduled Azure Function can make those things effortless.

That is all for today, and remember that you always have to protect your work, like a cat protects its spoils from a dog on the image below.

^{Dirk Valckenburg, A Cat Protecting Spoils from a Dog, 1717}
^{Cover image by Hebi B. from Pixabay}

Azure DevOps integration with Google Hangouts Chat

Igor Bertnyk — Tue, 03 Mar 2020 19:36:29 +0000

In my previous post:

User Experience: How to design a train station... NOT!

Igor Bertnyk ・ Jan 28 '20

#ux #design #productivity #architecture

we veered away to the topic of UX Design. Let's return to the Azure Devops and discuss various ways of its integration with third-party services and, in particular, with Google Hangouts Chat.

Azure DevOps Service Hooks

Let's imagine the situation when you want to receive a notification about new User Stories, Pull Requests, or Build completions on your favorite means of team communication, such as Slack or Microsoft teams. Or you want to trigger some workflow based on Azure DevOps event. Well, you can! Service hooks let you run tasks on other services when events happen in your Azure DevOps Services projects. Service hooks concept is based on a pub/sub model where a producer publishes events to the topic, and a consumer subscribes and handles those events.
If you open Azure DevOps/Project Settings/Service Hooks menu, you will see that there are a lot of predefined integration points, including Jenkins, Trello, and others. There is also a hook to the excellent workflow automation tool Zapier. It allows to easily integrate various services and APIs and I highly recommend it, although it is a subject for another post. Surprisingly, there are no predefined integration with Microsoft's own Microsoft Power Automate (formerly Microsoft Flow).

Azure DevOps Web Hooks

So what to do if your favorite service is not on the list? What if we want to send a message to Google Chat? Fear not, Web Hooks are to the rescue!
Web Hooks provide a way to send a JSON representation of an event to any public endpoint (HTTP or HTTPS). And that opens multitude of possibilities.
Let's create one. When we select a web hook option, we are also able to select an event trigger. Here we have all kind of triggers related to Pull Requests, Builds, Work Items etc. For the purpose of this post let's choose a "Work Item commented on" option, which triggers an event for every new comment posted on a User Story or a Task.

Next, we need to provide a URL of our public endpoint. We also have some options for authentication. And we can customize to some extent a level of details passed in the event. I will show you later in this post how to setup an endpoint. Let's pretend that we have it already at this point and enter into the form.

There is a convenient "Test" button that sends a mock event to the configured URL and allows you to see a JSON message format that we will use later to transform it to the format that Google Chat can understand.

Great! We finished Azure DevOps configuration. Now to the Google Hangouts Chat.

Google Chat Webhooks

Incoming webhooks let you send asynchronous messages into Hangouts Chat from applications, and they are fairly simple to configure. Let's create a new "DevOps" Room and in the members' menu select "Configure Webhooks"

Add a new webhook. We can also configure a custom bot image.

After we've finished with addition, a dedicated URL is assigned to the webhook. Please make a note of it as we'll need it in a moment.

Let's move to the final step and tie all of this together.

Azure Function

So now we have configured both Azure DevOps service hook and Google Chat webhook but they still do not talk to each other. DevOps sends a JSON message in a format that Chat is not able to understand. We need a way to transform the message an tie those two services together. There are a lot of options for that. We could use Zapier, mentioned above. Azure Logic apps has an integration with Google Chat out of the box. But why use ready-made solution when we can develop our own, right?
One of the option is Azure Function. It is simple, cheap, can be secured on a function or host level, and support Javascript language, among others.
I will not tell you here how to create a function, as there are many tutorials that go to excruciating level of details, for example here. On a screenshot below I've created a "WorkItemUpdate" function with HTTP trigger.

A code for the function is below:



const https = require('https');

module.exports = function (context, req) {
    context.log('JavaScript HTTP trigger function processed a request.');

    if (req.body && req.body.message && req.body.message.text) {

        context.res = {
            status: 200,
            body: 'OK'
        };

        const data = JSON.stringify({
            text: req.body.message.text
        })

        const options = {
            hostname: 'chat.googleapis.com',
            port: 443,
            path: '/v1/spaces/<space>/messages?key=<key>&token=<token>',
            method: 'POST',
            headers: {
                'Content-Type': 'application/json',
                'Content-Length': data.length
            }
        }

        const botReq = https.request(options, (res) => {
            context.log(`statusCode: ${res.statusCode}`)

            res.on('data', (d) => {
                context.log(d)
            })



            res.on('end', () => {

                context.done()
            });

            context.done()
        })

        botReq.on('error', (error) => {
            context.log(error)
            context.res = {
                status: 500,
                body: 'error'
            };
            context.done()
        })

        botReq.write(data)
        botReq.end()
        //context.done()

    }
    else {
        context.res = {
            status: 400,
            body: "Please pass a JSON body.message.text"
        };
        context.done();
    }
};

Please notice that "path" parameter in the code is the URL that we got from Google Chat webhook. The purpose of the code is to transform JSON received from DevOps event to the { 'text': 'custom message' } format accepted by Chat, and submit it to the Chat's webhook.

In the Azure portal we again see a convenient "Test" section where we can test our function in isolation. We can also see "Get Function URL" link.

Copy it, we need it now! Remember that we glossed over URL configuration for Azure DevOps service hook above? That the URL that we need to enter there.

Finally, all configuration is done. Let's enter a new comment in a User Story, and in a second it will appear as a new message in our Google Chat Room:

Conclusion

We have seen that Azure DevOps can be integrated with a number of services and were able to create a custom integration with Google Hangouts Chat using Azure function.
I hope it was useful, here as a cat (and a dog) for you as a proof that different species and services can live peacefully with each other.

DEV Community: Igor Bertnyk

Docusaurus authentication with Entra ID and MSAL

Introduction

Adding Entra ID Authentication

Registering a Single Page Application

Installing MSAL Libraries

Configuring Entra ID Registration Details

Adding Login Functionality

Code Implementation

Conclusion

Azure Container Apps - the future of K8s in the cloud?

What new service brings to the table?

Azure Portal

Microservices

Dapr

Google Cloud

Conclusion

The ultimate guide to hosting multilingual Angular application on Google App Engine

Google Secret Manager Configuration Provider for ASP.NET Core

SecretManagerConfigurationSource

SecretManagerConfigurationProvider

SecretManagerConfigurationExtensions

i-b1 / GoogleSecretManagerConfigurationProvider

Google Secret Manager Configuration Provider

A brief history of application architecture (of the 21st century)

Table of contents

N-Tier Architecture

Tiers and Layers

More complex implementation

Benefits and Disadvantages

Ports & Adapters

History

Motivation

Benefits

Components

Onion Architecture

Layers (rings) : Core

Outer Layers

Benefits and Drawbacks

Command Query Responsibility Segregation (CQRS)

Context and problem

Solution

MediatR

Next Steps

Event Sourcing

Designing Microservices:

How to pass Google Cloud Architect Certification exam

GCP Architect Exam

Exam preparation

In conclusion

Azure DevOps Multi-Stage YAML Pipelines for Google Firebase Functions

Deploying Firebase functions

Firebase Token

Azure Multi-Stage Pipeline

Variables

Tackling Approvals

Viewing deployments

Final words

Protecting Azure Functions with API Management Service

Enable APIM Managed Identity

Secure Azure Functions with Azure Active Directory

Finding AAD Application ID

Importing API to Azure Management Service

Applying Inbound Policy to the API

Checking Azure Active Directory Integration

Final thoughts

Azure DevOps Recipe: Deploying Google Cloud function to GCP

Using Google Cloud Build

Using Azure Pipelines

Setting up a Service Account

Storing service account key in Azure DevOps

Creating CI/CD pipeline

Final thoughts

Azure DevOps Recipe: Deploying Azure Logic App using Powershell Script

Creating a build artifact in Azure DevOps pipeline

Release pipeline

Powershell Script

Conclusion

A missing step: Backup Azure DevOps Repositories

Table of content