Our last posts covered structuring and securing your Azure environment. Now, we’ll focus on a topic important for its actual use: how strictly to control deployment.
What people often do is create a portal between developers and Azure itself. This isn’t surprising, as it’s probably what they have on-premises: a portal that exists between developers and the servers that run the applications.
I have seen organizations spend millions of dollars into custom portals in front of Azure. But these portals are based on an assumption—that such an interface is needed at all. And then here’s what happens: these portals either (1) slow down development, or (2) your users or customers will not use it and will instead go around you.
The better approach is to deploy into the Azure environment with code. You teach your application teams to use templates—not unlike what you’re probably already using, such as Ansible Salt or ChefPuppet. You use code to do the actual deployment of their servers and applications and manage your release management pipeline.
I have seen Fortune 50 companies force this approach on their users. And they’ve benefited by ensuring applications are built in a continuous deployment cycle.
Nervous about this model? You can take some comfort from the fact that the Azure environment portal is largely read-only. Maybe the QA environment isn’t, but the portal is.
Concerned your users simply won’t be able to deploy with code? You can teach them! I’ve seen forums be highly successful in getting this knowledge well-established.
Still not sure you can make it work? Then take a stepping-stone approach. Here’s what I mean by that: give your team write access in the Dev environment simply to “play around.” In this approach, your developers can use the Dev platform to establish provisioning. They then can export the template and, finally, build the template into your release management pipeline for deployment to the actual environment.
The reason I call this a “stepping-stone” approach is that you could include a custom portal that lets users handle provisioning as a learning process. That’s all the custom portal should do. Once provisioning is accomplished, everything else has to be deployed as code. In this way, the process becomes a learning experience for your team that prepares them for code-based deployments in the future.
The bottom line is to be wary of custom portals! And absolutely do not build a custom portal to let your users handle provisioning and moves/adds against your live Azure environment. I have seen this method used over and over, and it leads to disappointment and regret.
Instead, start out on the right path. Don’t over-intermediate—and teach your users what they need to know so they, and your organization, can succeed.