The Orange Bandits – Approach to CI/CD

With the rise of Citizen development, and low code/no code approach in Power Platform, organizations are facing new challenges regarding correct Application Lifecycle Management.

Citizen developers, often not having professional IT background, are often lacking needed knowledge to comfortably work with Power Platform solutions, not mentioning GIT source control.

In our team, we decided to implement Center of Excelence Application Lifecycle Management.

This allowed us, in a span of few hours, to have robust, controlable and reviewable history and version tracking for our solution.

We have decided to implement simplified version, with only two environments, Development and Production.

Instalation of CoE ALM kit is quite well described on MS Learn platform – https://learn.microsoft.com/en-us/power-platform/guidance/coe/setup-almacceleratorpowerplatform-preview, however in few points the documentation was a little bit outdated. This is expected, as this solution is still in Preview.

Also, you need to pay special care to any manual changes you make in DEvOps repository / configuration, as this can lead to unexpected results when running the pipelines.

One limitation that we faced, is that MS assumes the Azure Build agents are to be used, and does not allow one-place customization of Agent Pool used.

CoE ALM solutions installs two applications in Power Platform environment:

Second one is used for setting up the process and first one is used for managing the releases. Both of them offer user friendly visual interface to configure ALM process:

Triggering of solution deployment is as well user-friendly and hides the complexity of processes happening in the background:

In the background, multiple DevOps Pipelines are created and flow of solution is following:

Unpacked solution is available and versioned in GIT source control:

For each Solution Deployment Request, the PR is created and changes can be reviewed.

If this topic seems to be interesting for you, feel free to stop by our table for a chat! 🙂

Our deployment solution uses YAML and PowerShell scripts to ensure CI/CD

🤖 Automatically Priming our SPA cannons with React and .NET ⛵️

Sailing is though, so you need to rigg your ship to your advantage, preferably automating your sales and having people walk the plank for making bad code. We chose to created a project with ASP.NET Core application running with React.js. The application is running on .NET version 7 and uses several technologies, both hip and retro.

Screen capture of the .net SPA application setup

Mapbox for Charting the Seven Seas

Our application uses Mapbox – a provider of custom online maps for websites and applications. The company provides APIs and SDKs to create custom maps, add markers and other map controls, and to handle user interaction with maps. This ease of use and their clean and well-structured documentation (docs.mapbox.com) made Mapbox our top dog for create, edit and manipulate maps in our service.

Map created using Mapbox’s API

Protecting your Shared Booty form the Crew

Any pirate needs a secure lair, a pirate code and ability to help other pirates in need. For this reason we created a repository in GitHub and implemented best practices for collaborating as developers, like proper branching, build pipelines, linting and pre-deploy checks. Like blocking ourselves from bloat because we can’t have unused code in the repository.

Snipet showing lint error for unused variable

Branching Strategy for Division and Conquering

The master branch contains the production code. All development code is merged from develop into master. Cutting corners in true hacker style we opted to not use feature branches, since, to be frank, the entire thing is a feature at this point.

What we all said when discussing feature branches

All branches are protected with protection rules. Due to the limited size of the project we can automatically merge features and bug branches directly to develop, but we can’t push directly to develop. Even that is too risky for this group of mad lags and girl. If you want to merge code from develop into master you need approval from at leaste one other developer and no changes requested to your merge, if all flags are green Github forcefully collides the code together and see what sticks (it’s actually more sophisticated than this, but you Judges know a lot more about this than we ever will, so we humbly just call it “magic” – just like magnets).

Parchment showing the Law of Protection for our Master Branch

Feel free to have a gander at our code repository to appreciate all the shiny details: github.com/TommyBakkenMydland/CaptaIN-Hack-Sparrow

Smooth Rigging with CI/CD and Github Actions

Github Actions is a now a CI/CD platform that allows developers to automate their software development workflows. This, for us, is a huge win because we want to do as little configuration as possible!

CI/CD github actions

The actions reduce the time and effort required for manual processes and enables us to release new features and bug fixes quickly and confidently – Harr harr, got you matey, you thought we will fix bugs! … But … for the sake of argument … if we were to fix bugs, this powerful tool for streamlining development workflows, enables us to deliver high-quality software more efficiently and effectively at lower cost – Better use of time, reduce waste of time (WoT) and better business value for the client. We used yaml to tell what GitHub actions should create:

Yaml file describing what GitHub actions should create

Creating Overly Complex Gadgets to Avoid Simple Tasks
(aka How we used ChatGTP to give us documentation on Pulumi)

Nobody likes to know stuff. Everyone loves AI. What about AI that knows stuff?! Sold!! We used the AI service to provide us with documentation on how to deploy infrastructure in Azure with code.

Asking the oracle about stuff we probably already should know

From this we were able to write code that could be executed in our CI/CD

Pulumi snippet for creating our environment: Infrastructure as code #retro

Resulting in a beautiful environment and ample time for coffee ☕️

Screen grab showing the employed resources in Azure
Screen grab showing ChatGTP making a meme about making memes about using ChatGTP. Very meta.
Mame created from ChatGPD’s instructions

⚒️Dev and tooling ⚒️

Dev and tooling 

As part of our solution we are developing a Teams App for staffing raids, which uses an Azure Function App to get dataverse data. The toolchain setup for doing this consists of Visual Studio Code, Azure Devops Pipelines and Azure Services. 

To speed up our delivery we have implemented a CI/CD pipeline that deploys the infrastructure and backend code to an Azure Function App. The process works like this 

  • We develop a new feature with Visual Studio Code 
  • We push the feature to the main branch  
  • The Azure pipeline is triggered and executes two stages 
  • Build stage
  • The .NET code is built as a deployable zip 
  • Dev stage 
  • Then infrastructure is deployed with Azure Bicep 
  • The zip is deployed to the newly created Azure Function App 

We have modularized the stage jobs in templates, so we only need 9 lines of code to add another environment to our application. 

To deploy our infrastructure with Bicep we use a Devops Service Connection to authorize operations with the Azure CLI.

Take a look at line 49 – here we read the output variables from the Bicep deployment in order to retrieve the name of the function app. We later retrieve and use this Devops pipeline variable in the job that deploys the code to the Azure Function App.  

The infrastructure is defined in the .bicep file above which also utilizes other Bicep modules. In order to avoid explicitly including secrets we feed it from a Azure Key Vault. A link to the Key Vault Secret is passed to the Azure az group create command in a json file. 

We deploy a frontend-app as well. The build is made and artifacts are created for the spfx-app and for the teams-manifest. We then have a release pipelines that utilize npm and m365 cli for deploying the app to the sharepoint app catalog and to Teams. The scripts are written with powershell. 

For now it only displays basic pirate data from Dataverse 

Branch policies, infrastructure as code with Pulumi and CICD as code with yaml

👾🤓✋🏻😎✌🏻👾

Det er opprettet to brancher i vårt github repo.
Develop branch som holder kode for dev miljøet.
Master branch som holder kode for test og prod miljøet.
Det er implementert regler som krever at man setter opp PR,
og for å kunne merge koden til develop må en annen utvikler godkjenne koden.
Det er også implementert build check som starter automatisk når man setter opp PR, slik at man unngår å merge inn kode som vil feile i CICD.

Github branch policy
PR to master with build check

Mappestruktur

/nINjas

Inneholder vår SPA applikasjon med React og .NET6

/nINjas.Infrastructure

Inneholder ASP.NET med Pulumi

/python

Inneholder pyton kode for å ta bilde med rasbery pi og analysering av bilde

Infrastructure as code with Pulumi

Pulumi with ASP.NET

CICD as code with yaml


Deployment with the power of the shell

Vi har jobbet med å kjøre CICD i azure devops men har noen rettighetsproblemer så deployment er gjort med powershell:

Deploy infrastructure with pulumi commands in powershell
Failed deployment in AzureDevops but with more time it will work!

Kjører på en app service i azure: https://ninjas.azurewebsites.net/

Middle-age Mutable Ninja Tuples is scripting its infrastructure!

Our Blazor web app allows people to register as Turtles, meaning they will help others in need. In the field, Turtles use the official Dynamics mobile app. To use the official app, users need an Azure AD user with a Dynamics license and a security role in Dynamics.

Instead of having to manually create users in Azure AD and assign licenses and Dynamics security roles, this infrastructure is programmatically set up.

The backend of the Blazor web app uses a custom Azure API client which programmatically sets up the infrastructure: creation of Azure AD users and assigning of Dynamics licenses.

Because of our Infrastructure as Code, users are able to use the official Dynamics mobile app automatically after registering – no manual steps required!

The following image shows the method that creates an Azure AD user and assigns the Dynamics license.

Interaction with Azure AD is done using GraphServiceClient from the Microsoft.Graph NuGet package. Authentication is done using an Access Token retrieved using functionality from the Microsoft.Identity NuGet package.

Shell is power!

Can you feel the power of this?

In order to ship our components from development to prodction we have leveraged several technologies.

Dataverse

In order to export our solution for dataverse we have built a set of yaml based pipelines in azure devops. We have isolated the tasks to their own separate template files which are then called when needed, allowing for simple reuse of functionality.

Azure

To deploy our azure resources we have used bicep instead of armtemplates. These are leveraged in azure devops pipelines. We have created templates for the individual types of components as illustrated below.

PowerShell with Portals CLI

Power Apps Portals can be handled using Portals CLI that became available this winter.

Documentation here:

https://docs.microsoft.com/en-us/powerapps/maker/portals/power-apps-cli

ALM Best practise

Working this way is best practise for Application Lifecycle Management (ALM) and makes it possible to deploy portals to dev, test and production in a painful and fluent way.

Powershell with Portals CLI

We use PowerShell to handle Portals commands to authenticate, create auth profiles, download and upload portal content. This enables us to use Visual Studio Code when working with Portals code.

Auth

Download

Portal code in VS code

Governance on SharePoint site themes – Issue #1 now resolved

Github issue #1 is now addressed and resolved.

Iterating on the light/dark theme upload scripts TMNT IT management has added the capability to iterate over all SharePoint sites and apply the dark theme as default.

The updated script https://github.com/EivindBerge/PIZZA-TIME-ACDC-2022/blob/main/theming/site-theme-management-tmnt.ps1 is running in a scheduled Azure Run Book using PowerShell Core 7.1. SharePoint Online Credentials are as runbook credentials, which is sufficient for this scenario. Key Vault could of course be an option, or even better using a certificate – but as IT is very centralized this works for the time being.

Credential
Runbook
A job well done
Inverted theme applied!

We have also added more code and security scanning tools to also cover PowerShell scripts and find more general security issues.