In the next post in our Azure DevOps 101 series, we will start to look at the functionality of the product more, the first post gave us an overview of functionality but now I wanted to get into specifics. I’m going to start somewhere I’ve not seen most online guides go, that is projects.
While it may not seem like an exciting post to write, in Azure DevOps, projects are the lifeblood of Azure DevOps, it is where all of the features we discussed in the overview live and it’s where the configuration of those features at a local level is done.
Quick introduction to projects
First I want to talk about the outline of an Azure DevOps instance, here is a diagram to help explain.
At the top level, you have an organisation, it is the organisation that is in the URL where you login to Azure DevOps, for example: https://dev.azure.com/organisation. Next level down is your projects, these are the individual artefacts you create that hold users, work items, repos, test plans and various other project specific items. It is also a security boundary, if you don’t have access to a project you cannot see it on the main screen nor can you navigate to it using the URL.
Within your projects you also have Teams, a team is a collection of users but that team also has a backlog and board where they can see work items assigned to their team. This is done by area paths, which is basically a path from the project root. It’s a way of enabling teams to have work items assigned to them from the main project backlog. You can have any number of teams but every project always starts with at least one default team.
Other than the dashboards you will find within a project (a new post all together), each project has a basic informational dashboard, it shows some about information you can customise on the project, you may use this to explain what your project is, you can also use a readme markdown file from your wiki or a repository here as well. You will also get pill badges showing the percentage split of languages in the project, you can hover over them to find out the percentage of them.
You can also see a section for high level, basic project statistics, such as the number of work items created and completed, pull requests opened, commits and pipeline success for the last one, seven or 30 days, as well as the number of members in the project.
The number of settings available even at a project level makes Azure DevOps a highly customisable product, without having to worry about breaking changes when Microsoft perform upgrades. Due to that writing on the number of settings available would be a huge undertaking so I’m going to just focus on some of which I think are the most important.
First of all, on the Overview page, you will see the services available that we discussed in the overview. You can turn these off for a specific project if you don’t need then by switching the sliders, this removes the menu option from the navigation menu. It is also where you can see what process your project is using (the next post is on processes). Under the General section, this is where you can also administer your teams, add new ones, delete old ones and modify membership. You can also on a more granular level control permissions here and settings for notifications.
For many people, one of the most confusing aspects is the configuration of boards at both a project and team level.
From the screenshot above you can see both configuration options available. Obviously it’s easy to tell which one is for modifying configuration specific to the team and which is for project specific configuration. However, both of those configuration screens look very similar when you click in them. Just remember that anything in project configuration will affect everything in the project and team configuration will affect just he team you are scoped to.
I’ve heard a lot of people say that the repository functionality is not that feature rich, however you can through the Repositories option in the project settings set some basic policies, more options are available on repos themselves and will be covered in more detail. You have the option though to enforce the following policy options:
- Commit author email validation
- File path violation
- Case enforcement
- Reserved names
- Maximum path length
- Maximum file size
Through the same screen, you also have the ability to set security settings for tags and branches. As a branch level you can also add policies, such as approval rules, work item links, merge type limits, build validation policy, status approval from other services and even code reviewers based on the file type.
Lastly to speak about is the settings available around pipelines. It’s easy to set up pipelines and never really come into the settings options available, however you can in here set options around the number of days to keep artifacts and attachments produced as part of the pipeline, days to keep run history and pull request runs.
You can also configure sliders configuring the visibility of badges (you know those status icons you see in GitHub documentation, see below).
Additionally you can limit the variables that can be set and queue time, job authorisation scopes and publishing of metadata from pipelines.
Well I hope this gives you more insights into how to use some of the project configuration options, next time we will go into looking at boards and some of the functionality in more detail.