In this post I want to cover some advantages of creating your own Azure DevOps organization. Since I recommend it often enough.
Just over a year ago create your own Azure DevOps organization. Since this weeks T-SQL Tuesday contribution jogged my memory about it, I thought I would highlight some advantages.
Additional tips about creating own organization
Before I go any further, I want to cover some additional tips about creating your own Azure DevOps organization.
One key point to remember is that it’s always easier if you simply create your own organization on your own computer. Because things can become complicated if you decide to create your own organization on your work computer.
For instance, policies may prevent you from creating your own organization.
In addition, there may be company policies that frown upon you creating one whilst connected to the corporate directory. If the latter is the case, you can read the Microsoft guide on how to disconnect your organization from Azure Active Directory.
Personally, I recommend opening a browser in a Private/Incognito session and using your personal account if you really want to use your work computer.
Just bear in mind that your work computer may be locked down. Preventing you from doing things like setting it up as an Azure DevOps agent or installing Docker Desktop.
In addition, Docker recently changed their terms of use for Docker Desktop. You can read more about how the changes apply to Docker Desktop in section 4.2 of the Docker Subscription Service Agreement.
Another thing to remember is that some services require your Azure DevOps organization to be connected to an Azure Active Directory to work properly. For instance, Azure Synapse Analytics.
To get this to work you can read my post on how to configure your own Azure DevOps organization for Azure Synapse Studio Git integration.
Advantages of creating own Azure DevOps organization
In reality there are quite a few advantages if you create your own Azure DevOps organization. You can read a list of some of them below.
Full permissions in your own organization
For a start, it allows you to have full permission of an organization. So, you can experiment with all the settings. Like what certain policies do.
In addition, you can install various extensions from the marketplace without needing approval. So that you can test them. For example, earlier I mentioned Azure Synapse Analytics. In the CI/CD guide for workspaces by Microsoft it mentions that you need to install an extension.
Testing extensions elsewhere can be useful if your company has a policy about extensions. In fact, Microsoft has a guide on how to evaluate a Marketplace extension publisher that can help you.
Of course, it also means you have full permissions to create projects and change their settings as well. Allowing you to create service connections to your personal cloud accounts for use. For instance, your own Azure or GitHub accounts.
It also allows you to connect your own GitHub account to Azure Boards as well. Opening up some very interesting options whilst you work with boards.
Creating a custom process in Azure DevOps
Since we are on the topic of Azure Boards. Creating your own organization allows you to create a custom process for Azure Boards and test any changes you want to make.
You can do this with ease within organization settings by making a copy of an existing process.
For example, a new process based on Scrum. Once you are happy with your changes you can look to change them for the project you use at work.
Remember though, if other teams are using the same process ask them first before you make any changes. To avoid them having any surprises when they open up their work items.
Git repositories for Azure Data Engineering services
Another advantage of having your own organization is that you can integrate Azure Data Engineering services that you are testing with your own Visual Studio subscription with Git.
For example, Azure Synapse Analytics and Azure Data Factory services that you have deployed in Azure using your own Visual Studio subscription.
Bear in mind that some of these services, like the two above, require Azure DevOps to be connected to an Azure Active Directory. To help with this, I have written a post on how to configure your own Azure DevOps organization for Azure Synapse Studio Git integration.
Personally, I recommend creating a new Project and calling it something like ‘Azure assets’ to store all of these together. After doing this, you can create a separate repository for each service you are testing inside Azure Repos.
Sharing an Azure DevOps organization
Creating your own Azure DevOps organization also means you can share it with friends elsewhere. Because the reality is that a lot of companies will frown on you giving your friends access to their organizations.
Sharing with others can bring you some advantages. To get a better idea about this you can read my post about sharing personal Azure DevOps organizations to test SQL Server deployments.
Staging area for files containing sensitive details
You can use your own Azure DevOps organization as a staging area for files that contain sensitive details. So that you can sanitize them before copying them into your work environment.
For example, say you are testing a pipeline that deploys something to Azure in your own subscription. You can use this staging area to remove all the sensitive details like subscription ID’s from your pipeline here first. Plus, test that the pipeline still works if you decide to move the sensitive information to variables in a variable group.
Once you are happy you can copy the files elsewhere. Doing this ensures that there is no history of those details in the repository you use at work.
Testing pipelines in your own organization
Talking about pipelines, one very big advantage of creating your own Azure DevOps organization is that you can test pipelines in there.
You can test whatever you want without fear of causing problems. Especially if you are testing on your own computer at home.
For example, you can set up your laptop as an Azure DevOps agent and then run a complex pipeline. Like the one below that deploys an update to various SQL Server related databases. Databases that are both on-premises and in Azure.
You can find out more about the pipeline above in my post about deploying to multiple SQL Server database types using Azure DevOps.
Of course, your complex pipeline can deploy to a vast number of other services as well as SQL Server related ones. Both on-premises and in the cloud. You can find plenty of examples online of services you can deploy to.
Complex permission structure
You can create a test project to test a complex permission structure that you are thinking about. Without the risk of causing issues in the workplace.
However, do bear in mind that the more complicated you make it the more time and effort is required for administration.
It might cause problems if your team wants to work in a DevOps related way. With this in mind, always check if this is needed.
Final words
I hope this post about advantages of creating your own Azure DevOps organization has given some of you ideas. Because it can bring many benefits and allows people to try new things more confidently.
With this in mind, I want to encourage more people to do it.
Of course, if you have any comments or queries about this post feel free to reach out to me.
Be First to Comment