Undoubtedly DevOps serves the importance of planning, building, testing and finally delivering a software fast with a reliable and efficient way. In my opinion, it is a way of thinking enabling people and teams to collaborate with an effective way sharing each one their thoughts and goals. We already use DevOps everyday in our life, we plan to do something, we try to build it , we test it and finally we get this done (most of the times!).
This is what DevOps is, a way of thinking..

DevOps is a big chapter so I decided to separate this post in three parts:

Part A: “Starting with Azure DevOps”.
This part consists of creating an organization, project, examine the access levels for users, the process of connecting an Azure Active Directory to DevOps instance and finally invite a user to contribute to a project.

Part B: “Code Management”:
In this part I will show you how to connect a GitHub repo in Azure DevOps and how you can explore Azure repositories making commits, revert changes and pull requests to your code.

Part C: “Create a Continuous Deployment Pipeline”:
In this part I will show you how you can create a Continuous Deployment Pipeline (build and release) through Azure, in order to finally publish the web app.

Prerequisites for part A:

  1. A GitHub account with at least one repository.
  2. Account in Azure (if you don’t have one, you get a free account here:
    https://azure.microsoft.com/en-us/free/
  3. At least one user must be added in your Azure Active Directory (your default AAD in case of free account).

For testing purposes, I have created a repository in GitHub with the name NFL, which can you find it here: https://github.com/jdk1900/NFL
As you can see below, this repository consists of HTML5, CSS and JavaScript files representing a simple validation form. I did not spend much time in coding because coding is beyond the scope of this post, I focused only to represent the Azure DevOps features. The reason I have created this repository is because we are going to use this one for our Azure DevOps project.

Part A (Starting with Azure DevOps)

In general, when you think of Azure DevOps it is good to consider it like a structure, like a flow chart. Obviously, you need to have an account, next you will likely create an organization and under this organization you will certainly create a project. But, eventually you will need to add user(s) and enable them to collaborate to your projects either directly to a project level or to an organization level but remember, you need to assign access levels to those users manually or using group rules.

To start with Azure DevOps, visit https://dev.azure.com and in the pop-up window press Continue.

In the next window name your organization and select in which region your project will be hosted to, in this post we name it “SoccerUS” and this will be hosted to in Central US:

Press continue and wait while the organization is being created.

In a few seconds we get the following screen. Here, we need to define two things:

  1. The name of our project, in this case NFL (National Football League).
  2. The visibility: Public or Private (this can be changed later) but for now, and to keep it as simple as we can, we select Public and click on +Create project.

After clicking +Create project, you get the welcome screen and as you can see on the left side of the screen, the Azure DevOps tools are now available to use them. Please note also the right side of the screen where you will find the button “invite”. From there you can invite people inside your organization (or outside) to contribute to your project.

In our example we want to invite someone from our Active Directory to contribute to our project. That is fine, but first we must establish a connection of our Azure AD to the Azure DevOps instance. As I mentioned in the beginning of the post, one of the prerequisites is to add at least one user in your Active Directory because after establishing the connection between the AAD and Azure DevOps, we are going to invite THIS user to our project.

For the post purposes, I managed to add the following user to my AAD:

So now I am going to connect the Azure Active Directory with Azure DevOps.
Click the Azure DevOps image in the top of the screen:

this will take you to the central page, where you can see all your projects. Now go to the bottom of the screen and click on “Organization settings”

Now click on Azure Active Directory as shown:

Next, you will see a new window with the button connect directory.

After pressing the Connect button you get the following screen.Here, you simple select your Active Directory and the Tenant you want to use (in case you have more than one):

Then, you click on Connect getting the following notification:

Now we have connected our Azure Active Directory to Azure DevOps the next step is to invite the user from our Active Directory. At this point It is good to know that before inviting a user(s) in our project we need to decide what access level will be assigned to this user. There are three types of access levels:

  • Visual Studio subscribers are detected automatically when they sign in. There’s no additional charge for users with a Visual Studio subscription.
  • Stakeholder is a free access level with limited functionality.
  • Basic is free for the first 5 users, and paid for 6 or more users.
  • Basic + Test Plans is paid only, but is free to try for 30 days.

Also keep in mind that all new users get the free Stakeholder access if they’re added directly to a Project. That way you aren’t surprised by charges for new users who weren’t added directly to the organization by a Project Collection Administrator. You can still choose a different path if you want to invite a user to your project avoiding the default Stakeholder role:

Go to your Organization settings and choose Users.

Click on Add User in the right of the screen:

Here you can choose the access level, in which projects will this user be invited to and you can also add this user to an Azure DevOps Group.
As a conclusion, you have two different ways to invite a user: the first is to invite the user through your project’s summary page but with the Stakeholder Access level:

And the second, to go through your organization’s settings as shown before.I strongly recommend the second option because this way you can have more granular control for the users you want to add and also you can leverage the automate access level assignment by adding them in groups rules so you will not have to assign access levels manually every time a new user is added.

That’s it!

Thank you for reading this post!
I hope you found it useful, simple (as much as it can be!) and easy to read. See you in the Part B of this post.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.