Sharing personal Azure DevOps organizations to test SQL Server deployments

Reading Time: 7 minutes

In this post I want to share some tips if sharing personal Azure DevOps organizations to test SQL Server deployments. So that others can benefit from doing this.

MVP

Before I get started I just want to say a big thanks to some of you for the response about me becoming a Microsoft Data Platform MVP over the weekend. Trust me, it means a lot and is going to take a bit of getting used to.

Of course, a big thanks to both Sander Stad and Jan Mulkens as well. For both nominating me.

I thought I better post about something which highlights sharing and collaboration. Because this is my first post since I became an MVP. So, I thought this was fitting.

Own Azure DevOps organization

It’s good practice to have your own Azure DevOps organization if you are working with Azure DevOps. Because it has many advantages.

For instance, if you want to test new things without the risk of affecting the Azure DevOps organization you use at work.

In addition, you can do things that you do not have permissions to do in your works organization. Such as sharing personal Azure DevOps organizations to test SQL Server deployments.

Once you have created your own one it is easy to give somebody else access to it. You can read how to create your own organization in detail here.

Sharing

Now there are some situations where it’s good to share your organization with somebody else.

For instance, when you want to test something with a colleague outside of the Azure DevOps organization your company uses.

It’s also a good thing to do if you are co-presenting an Azure DevOps session. Because sharing your organization strengthens your collaboration efforts.

I’ve done this myself. You can end up with some really interesting deployment pipelines using this method.

It also brings along other benefits as well. For example, you can organize yourselves better. Plus, it is a lot better to present from one organization. For both the speakers and the audience.

With this in mind, I want to share some useful tips to help you with this.

Adding a user

To start sharing personal Azure DevOps organizations to test SQL Server deployments you must add a user first. You can add a user by going to your organization settings and selecting ‘Users’.

After adding somebody it is important to decide on their access level. You can also choose which projects they have access to.

If they are simply viewing your Azure DevOps organization you can choose to make them a stakeholder. However, if you want them to contribute they should at least have basic access.

In addition, if they have a Visual Studio subscription adding them as a user can bring some benefits. Especially if they have a Visual Studio Enterprise subscription.

Because within your private projects you get an additional self-hosted parallel job for every user in your organization who has this subscription.

You can read more about this in detail here.

Now whether or not you change their permissions is entirely up to you. Because it depends on what you intend for them to do.

You can leave their permissions as standard. If you want them to have total control of your projects you can add them to the ‘Project Collection Administrators’ group.

However, I only recommend doing this if you fully trust them. Due to the fact this gives them a high level of rights within your organization.

You do need to be aware of what you are allowing them to do if you add them to this group though.

For instance, they will be able to add extensions from the marketplace themselves. Without needing your approval.

Which can be fine. Just remember that there have been some concerns about the level of testing for some extensions.

Notifications

Another thing to bear in mind is that if you add somebody to the above group they will get email notifications. Especially if you leave your notification settings as default.

Of course, if you are the guest user and testing something this can be great.

Because it means whilst a deployment pipeline is running you can do other things. All you have to do is wait for the email to say it has finished. On the other hand, if you are testing your pipeline and it fails your colleague can also see it.

With this in mind, a piece of advice if testing a SQL Server deployment pipeline in somebody else’s organization.

Test as much of it as possible in your own organization first. Even if that means having the same setup. It does mean a bit of extra effort on your part. Especially if self-hosted agents are involved.

However, it does avoid the person whose organization you are using receiving a lot of emails. Which can lead to other issues.

Of course, you could always change the default notification settings instead.

Project collaboration

Anyway, lets focus on the benefits of sharing your organization and collaborating on projects. Because this opens up some interesting possibilities.

Sharing your organization allows you and your colleague to get yourself organized. You can do this by using Azure boards. Something I talked about in a previous post here.

For instance, if you are co-presenting a session with somebody you can use sprints for presentations. Using the sprint task board to share out the work.

In addition, if you present multiple sessions together I recommend installing the ‘Team Calendar’ extension from the marketplace.

After doing this you can use the Calendar to enter all your speaking dates. You can even color code your events as well. By putting them in different categories.

Reciprocating trust

Now trust should always be a two-way thing when sharing. If somebody trusts you enough to give you a high level of permissions in their Azure DevOps organization than it’s only fair that you should reciprocate.

A good way to do this is to share your own resources with them within Azure DevOps.

For example, you could allow a project in their organization to create Azure SQL Databases within your own Azure subscription.

Authorizing use of your Azure subscription inside somebody else’s organization may look easy. However, deployments are not always a smooth process. So, you might want to use an alternative solution instead.

One option is to connect to your Azure subscription using a service principal instead. Like the example in this post here.

One thing to think about if somebody does give you the rights to add objects to their Azure account. Which is that if you create a large resource remove them afterwards.

If you are unable to do this yourself let your colleague know. Otherwise they can run out of Azure credit.

Docker containers

Another interesting aspect if you collaborate in projects with somebody else is that it gives you some other interesting deployment options. For instance, you can do various things with Docker containers locally.

Recently I covered how to do a couple of interesting things locally on your own computer. As you can see in the below posts.

• Set up your laptop as an Azure DevOps agent to test SQL Server deployments
• SQL Server installation options to test Azure DevOps deployments locally

Using these posts gives you some interesting options if you are sharing somebody else’s organization. Especially if you are testing a pipeline that updates SQL Server instances within your network.

Of course, the above posts can also be useful if you are testing things on a budget.

Options

One option is that you configure just your computer as an Azure DevOps agent. In addition, install Docker containers locally on your own computer.

After doing this, both you and your colleague can test SQL Server deployments. Using the Docker containers that are on your computer.

Of course, this does mean your laptop has to be on when either of you are testing your deployment pipelines.

Another interesting option is a bit more flexible. Because it allows either person to test the deployment pipelines locally and independently. It is more complex though and involves the below steps.

1. Both of you configure your computers as Azure DevOps agents.
2. In addition, you both install Docker and Azure Data Studio locally.
3. Afterwards one of you creates a new Git repository in Azure Repos.
4. One of you creates a new Git repository locally. Setting the repository in Azure Repos as the origin.
5. From there they use the deployment wizard in Azure Data Studio to create new containers. Saving the notebooks to the local Git repository.
6. Afterwards, they sync their local repository with the one in Azure Repos. Which they can do in Azure Data Studio.
7. From there, the colleague gets the notebook files from Azure Repos. So that they can use them to create the same containers on their own computer. Using with the same sa passwords.

Of course, doing the above takes some effort. However, it does mean either of you can do deployments whenever you want to. In addition, it’s one way to test that you have configured your self-hosted agents properly.

Another good point about using the above method is that it adds some redundancy. Because if one computer breaks you still have the other.

Alternatives

Of course, both of you can both just have a local instance of SQL Server installed instead. After working with stages in Azure Pipelines I do prefer the Docker approach though.

Because you can use a separate container to represent each stage. Like in the below example.

In reality, if you both want to deploy to containers it can be easier to deploy to a server running Docker Engine instead. Or a cloud-based service which hosts them.

Another option is to deploy to Azure instead. Which gives you a lot more options. Of course, you will have to do this if testing Azure SQL Database updates.

Like all things relating to SQL Server, it depends. I just want to give you an idea of what is possible with a bit of imagination. Because there are so many possibilities when you are working together on deployment pipelines.

Final words

I hope my tips about sharing personal Azure DevOps organizations to test SQL Server deployments has given some of you ideas.

Because I truly believe this is a good way to improve collaboration if using Azure DevOps. Which is why I want to encourage others to do it.

Of course, if you have any views or questions about this feel free to reach out to me.