Skip to content

Pipeline deployment custom branding

Table of contents

Introduction

Identity platform published pages can be fully customized. Customization enables companies to brand their sign-in pages so they share the look and feel of other company pages.

Custom branding explains sign-in page styling.

Management of custom branding files, primarily uploading of files, can be done in two ways:

  • The manual way leverages a PowerShell script. This will be the fastest way to work with custom branding files in the development environment.
  • The automated way when working with Azure DevOps repositories and pipelines.

Upload files using Azure DevOps pipeline

There are pipelines created for uploading / publishing of branding files to all environments.

  • Branding - Development
  • Branding - Test
  • Branding - Production

Pipeline execution

The configuration of pipelines triggers can be split into two categories:

  • Automatically triggered
  • Manually triggered

NOTE!

All pipelines are configured to require approval before running.
Members of project group Contributors can all approve runs, including their own.

Development pipeline

Automatic pipeline triggering is configured deployment of branding in the development environment.
When the pipeline discovers changes committed to the branding folder, regardless of branch, the pipeline starts running.

This means that every for pull request (PR) merged, that makes modifications to files in the include path, triggers the pipeline to run, in the same goes for any branch making changes to these files.

This is the (current) configuration for the development environment:

trigger:
  batch: true
  paths:
    include:
      - Pipelines/Dev-branding.yml
      - Pipelines/Templates/Template-branding.yml
      - Environments/Development/branding

Test and Production pipelines

For test and production, a manual action is required to trigger pipeline for deployment of branding files to respective environments.
There are no "Environments/<Test/Production>/branding" folders, the Development files are generalized so that they can be promoted to other environments using environment specific parameters.

This is the (current) configuration for the test and production environment (replace Test with Prod):

trigger:
  paths:
    include:
      - Pipelines/Test-branding.yml
      - Pipelines/Templates/Template-branding.yml

Pipelines in all environments are configured with includes to their own yaml pipeline configuration files.
With pipeline configuration changes, the pipelines will trigger and start (but will require approval to run).

How to work with an Azure DevOps repository

Pushing changes to a central source controlled repository usually involves Git and an editor. Microsoft's Visual Studio Code is a good and lightweight alternative, albeit some extensions may improve the user experience.

The procedure for working with online repositories is very similar regardless of vendor.

The following (recommended) procedure uses an Azure DevOps repository (other popular alternatives are GitHub and Bitbucket).

  1. Branch out from the main branch (using graphical user interface or shell / terminal)
  2. Make code changes in the new branch
    1. If environment is Development, it is convenient to manually upload files
    2. Eventually, manual upload files will only be possible in Development as all changes to Test and Production should be fully automated
  3. Upload changes and test Azure AD B2C pages to verify that modifications were successful
  4. Now the working branch are ready to be merged to the main branch, so everyone with a copy of the repository can get the latest version
  5. Create a pull request that pushes changes from the working branch into main
  6. Double-check the proposed changes (Files), assign (one or more) Required reviewer and select Create
  7. When the PR is created, make sure that there are *no* Merge conflicts
  8. Inform reviewer(s) of PR (copy and share the web site link in the browser address field)
  9. Configure Auto-complete (Merge type Merge - Delete <working branch> after merging) for automatic merge or wait for PR to be approved, then select Complete
  10. Switch back to main branch, pull newly applied changes, delete working branch

Checking in files to git repository with Visual Studio Code

The following procedure is based on Visual Studio Code.

Any other editor of choice (often referred to as ISE - integrated scripting environment) can be used as git is installed and works independently.

How to Install Git (and / or download).

Branch out from the main branch

In Visual Studio Code create a new branch by following these steps:

TIP!

First clone the project repository (this will create a local folder)

Branching - graphical user interface

  1. Press "F1" and type "create branch"
    1. Select "Git: Create Branch..."
    2. Enter the "working name" of the new branch
  2. Make changes
  3. Test changes by uploading files (for the development environment)
  4. Commit changes
  5. Push changes
  6. Create pull request (PR) in Azure DevOps, either yourself or have someone else create one
  7. Approve and merge PR
  8. Switch to main branch, pull changes, delete branch (optional, but recommended)

Branching - terminal / shell

By supplying the -c parameter the git switch command creates and switches to the branch:

  1. git switch -c <new branch name>
  2. Make changes
  3. git add . (or git add *) (adds all changes, single files can be select instead)
  4. git commit -m "<commit message>"
  5. git status (see which files are committed)
  6. git push -u origin <branch name>
    (The -u == --set-upstream and is a one-time operation to create the new branch in Azure DevOps, new commits only need git push)
  7. Create pull request (PR) in Azure DevOps
  8. Approve and merge PR
  9. git checkout main
  10. git pull
  11. git branch -d <new branch name> (deletes local branch, optional, but recommended)