EDIT: we added some more technicals details about different aspects of our ALM process regarding the most technical parts of our solution!

Since we are dealing with a Java Minecraft plugin in our solution, we need some special gicky and interstening elements in our ALM pipeline. I will go through that now!

Source control

On the Low Code part, as showed before, we are using Power Platform Pipelines and the git control OOTB functionality. It was a great balance between easy implementation, tracking changes, having always a backup available and of course ease the deployment of our solutions through our environments.

On the Pro Code part, of course source control is an essential part of our solution as well! (Not using git for it would be criminal!). We optet for storing all the elements on our solution in a single repository, since we are just two developers who work well together and use branching for working on and deploying our changes.

This is what our repository looks like!

• CSharp: we are storing here our main C# solutions. That is:
  • AzureFunctionsApp: different Azure Functions we use for integrations.
  • DataverseJobs: one time jobs and scrapping and testing to Dataverse and endpoints.
  • EarlyBound: generation of Early Bounds to work more effectively.
• Docs: we store all our docs here, which are sincronised used the Wiki as code functionality in Azure DevOps.
• infra: we store here all our infrastructure (CI) code, and some of the CD part of it.
  • biceps: our biceps code is stored here, as we use IAC for Azure.
  • scripts: we have a lot of useful scripts for easing the configuration of our VM, setting up our Minecraft Server, updating our plugin…
• plugins/PointPixelAPI: this is our Minecraft Plugin. Here resides all the functionality we developed for it, mainly our Minecraft shop, autoctrafting system and API endpoints.
  

Continous Implementation (CI)

The first part we consider in this process is how we deploy all our resources in Azure. Since we are continously deploying new things, we use biceps code to ensure every customization made happens without manual intervention and, in case the unimaginable happens, we can always roll back.

That includes AIFoundry, AzFunctionApps, Keyvault, Purview, a VM…

We are also using Managed Identity, so we also set the access between resources through biceps code.

Also, we have some scripts for automatically installing PaperMC and configuring the Virtual Machine so that we are able to connect to it and play. Also, we assign the VM a static IP.

Security and authentication

For security and authentication in Azure we opted to go for RBAC access management + automatically created Managed Identitities.

And of course, we are using Keyvaults for managing our secrets throughtout our whole solution:

Continous Deployment

We have been mainly using scripts for deploying our plugin to our Virtual Machine. That way a process that might see quite tedious (building in Maven -> connecting to VM -> transfering plugin build -> restarting server -> checking server restarts successfully) happens seamlessly!

Small comment: I am the developer and I’m very biased of course, but it’s tiny little part absolute fauvorite of the project! Hehe.

After that, we also set a pipeline to run that command at the speed of a commit push merge to main branch.

Testing process

Since we are two developers developing our Java Plugin at the same time, we agreed on setting some unit testing. That way, we make sure core functionality in the app never gets broken as we agidly add new functionality!

Documentation

Part of the good communication and ease to work together on a team comes from having good documents we all read, contribute to and comment!

Here is ours 😛

Thanks for following along! 😀

---

PointPixels care a lot about Governance. We have made sure we follow good principles for ALM by creating DEV – TEST – PROD environments, and having the TEST and PROD environment as Managed. To make sure we can have a coffee and watch the solution update process without touching anything, we have enabled Power Platform Pipelines as well 😉 As you can see, we avoid to use and build stuff in the Default Environment.

The environments are also restricted to a specific Azure Entra ID group to ensure that only the necessary people have access to them.

Using solutions… Yes, we know it’s given, but we mention it because it’s important and required in order to use pipelines in Power Platform. All of our components are packaged in solutions, and these solutions are then used to update TEST and PROD environments with changes and updates.We have dependent solutions that has to be deployed in sequence. The PCF solution and Custom Connectors has to be in the target environments before we can deploy the main solution.

We used Privileged Identity Management for activating Global Admin for our users only for a period of time instead of permanently. We needed to have the Global Admin role to enable features like

Power Platform Pipelines. We installed the Power Platform Pipelines App in the host environment, DEV – ACDC 2026. That had to be done in order to use pipelines.

We then connected to TEST and PROD environments so that we could do deployments from DEV all the way down to PROD.

Running the pipe! Starting deployment from DEV to TEST.

Deployment in the making.