Now that you’ve looked at the capabilities of the professional DevOps environment and a mix of tools that can be a part of it, we’ll drill down into each product within the Azure DevOps family and set it up in the proper way. You’ll certainly want to customize the configuration, but your suggested configuration works great in 80% of the cases. If you’ve already read the book The Phoenix Project by Kim, Spafford, and Behr, you’ll recognize the principles we implement in this chapter. You might want to create a new project so that you can test different configurations as you read. Once you have your Azure DevOps project created, take a glance at your project settings, and select the products that you’d like enabled.
Change your Process Template
This marketing department has decided that they only need three levels of work. A Campaign can have multiple Campaign Items or Product Backlog Items. A Campaign Item and a Product Backlog Item can have multiple tasks. At the top level, they can track at the Campaigns level or the Execution level. An individual iteration or sprint is tracked with tasks. You can have any number of higher-level portfolio backlogs if you need higher levels of groupings. Even while the built-in process template includes Epic ➤ Feature ➤ Product Backlog Item, you’ll quickly outgrow this because it won’t match your organization. You need to disable most of the built-in work item types and create your own so that you can name them and put only the fields and the progression of statuses that make sense in your teams’ environments.
Business initiatives
Marketable features
Plannable work to budget, schedule, and fund
Individual tasks to get done
By determining ahead of time what the process is to take a certain level of work item from creation to done, you organize your team. Each state, or board lane, should be owned by a type of role. For example, if you have a stakeholder designated as the person who’ll give the go ahead on the sketch of a screen before it’s developed, that stakeholder should have a column where they own the work within it. Each work item is represented by a visual card on the Kanban board, and the cards in their column are theirs to work. If the stakeholder does nothing, cards pile up in that column, and nothing is developed because of the bottleneck in that column. A dashboard report can bring this to light on a daily basis so that no column has too much work in it. The stakeholder’s job would be to either approve the sketch of the screen or initiate a conversation to fix it. In no case would you want a bad screen to be coded. That would be worse. By creating a good number of columns, mapped to the states of the work item, you can move the work through a known process where every column has a type of role responsible for performing a known set of work and then forwarding the work in process WIP to the next column. From a quality control perspective, every person starting on work has the obligation for inspecting the WIP to see if the work is ready for them yet. If something is missing, you stop the line and get it corrected before propagating the error further downstream.
For the purposes of software teams, the level of backlog that is prepopulated with Product Backlog Items in the case of the Scrum process template, or User Stories in the case of the Agile process template, is the appropriate level for doing branches and pull requests as well as designed test cases, as you’ll see a bit later in the article. Iterations or sprints can be planned with work items from this level. Then, tasks can be organically created, completed, or destroyed day by day. It’s often good to make plans based on the lowest backlog level and then break those down into tasks as needed on an ad hoc basis during the sprint.
Types of Work Items
Depending on the process template you choose when you create your project, you’ll start with a predefined set of work item types, statuses, and swim lanes in your boards. You should change these because there are only three process templates built in, and they are all very basic. Don’t expect to use them without customization except for very simple projects. You have three process templates to choose from when starting a project. If you have already created a project, and you want to choose a different process template, you are out of luck. Create a new project. If that ship sailed long ago, don’t fret. You can morph any of the project templates into just about anything you want.
The choices for project template are CMMI, Agile, and Scrum. The Scrum template is probably the most widely used at the writing of this book, and it is the template that is maintained the most. But the Basic template is new, and has been simplified down to just the basics. If you don’t know what process template to use, and you don’t know the difference between these, choose the Basic template,1 and modify it from there. It is the least prespecified, and you’ll be able to add anything you like.
You can see how similar the process templates are, and you should examine each one to gain some ideas because each work item is configured with a certain number of fields, and the fields of each are likely not going to fit your needs. As with a database schema if you go forward with tables and columns that are not used, your data set ends up with many null values. This causes confusion with reporting. If you are not going to use a field, customize your template and remove it or hide it from a work item. Simple is better.
As you can see, the process templates start to diverge at this point. You can hide fields of the built-in work item types, but you can’t remove them. It’s a cleaner work tracking data model to add custom fields rather than hide most of the built-in fields.
Customizing your Process
The preceding Figure 4-7 might seem like too many states if you are working by yourself, but by the time you have three or more developers on your team, you’ll be glad you are able to see where the work is. Without this structure, you will forget what is holding up each card of work. Let’s simplify these states so that we can see a different view:
Idea/Backlog
Definition
Design
Test Spec
Implement
Inspect
Test
Stabilize
Release
- 1.
Idea: Faulty concept of what to build
- 2.
Definition: Analysis gaps or unclear scope of what to build
- 3.
Design: Technology/architecture/pattern decisions needed in order to build
- 4.
Test Spec: How to know when you’ve build everything you need to build
Again, if you are building the software as a team of one or two, you can simplify this down because you communicate frequently and take care of these things as they come. For teams larger than that, you need these concepts in some form, regardless of what you decide to name the states or columns.
Working with the Process
Now that you have determined for your organization how many stages, or swim lanes, are appropriate, you’ll need to integrate your version control system with Azure Boards in order to be able to track every code or asset change that is associated with a card (or work item, within Azure Boards).
Linking Commits
All it takes to link a commit with your work items in Azure Boards is to start the commit message with the work item number. You should do this every time, even if you are working by yourself. Along with better traceability on what changes a work item required, it will encourage the team to control scope and stay on track by only making changes for the work item in front of them.
Staying in Flow
As a developer, it is easy to get distracted when browsing code because you will see refactoring opportunities and you will want to make the code better. It is not uncommon to look up after an hour of coding work to realize that you aren’t even working on the item you set out to complete. By setting a team rule that you will always link commits with a work item, you can keep yourself and your teammates on the most productive path every day.
In Figure 4-10, you can see that work item #412 has been linked with two git commits and the two resulting builds that contained these commits. If you tag your commits but don’t see this automatically, check in the Azure Repos settings that a teammate hasn’t turned this off. It is on by default for new projects but may not be on by default for repositories that were imported from outside sources. In that case, you’ll need to enable it for the new repository.
Branching from Azure Boards
When working with work items of any type in Azure Boards. you’ll want to build them up throughout the process. As you analyze the needed change and create screen mockups or any other document, either attach the document or include it inside the Git repository itself. When you are ready to begin coding, create a branch. If you know how to organize your branches, then you are ahead of the game. If you are wondering what branching strategy to choose, then keep it simple and use plain feature branches instead of a “features” namespace. For more research on available branching strategies, see the Branch Organization docs from Microsoft.5
You can create any branching scheme that you can imagine, so keep it simple. Place the work item number at the beginning so that you’ll be able to find your branch. Then, use all lower case with dashes. You can’t use spaces in a branch name. An added benefit of including the work item number in your branch name is that it will be a constant reminder to stay on track and only make changes that are needed for the current work in front of you.
Any commits you make with then stay on the new branch. If you break down features into user stories and tasks, remember to tag the commit message to the most specific work item you are working on. For record-keeping, you’ll have a branch that corresponds to your feature (or issue, or user story), and then you’ll have individual commits tagged to it or any of the children that you’ve worked on.
When you have completed the work and are ready to merge your branch back in, you can create a pull request.
Merging Using Pull Requests
Wrap Up
When using Azure Boards to manage your software project, you benefit from the automatic integration with the rest of the Azure DevOps family. This chapter, while showing some fantastic capabilities, only scratches the surface on the power of Azure Boards. The purpose of this book is not to be a comprehensive feature guide for Azure DevOps. For more reading on Azure Boards, visit the official documentation.6
Armed with this tool, you have a world-class project tracking capability, enabling you to focus on your code. In the next chapter, we’ll look at Azure Repos, but more importantly, how to set up your Git repository for success.
Bibliography
Adopt a Git branching strategy. (n.d.). Retrieved February 18, 2019, from https://docs.microsoft.com/en-us/azure/devops/repos/git/git-branching-guidance?view=azure-devops
Azure Boards Documentation. (n.d.). Retrieved from https://docs.microsoft.com/en-us/azure/devops/boards/?view=azure-devops
Beck, K., Grenning, J., Martin, R. C., Beedle, M., Highsmith, J., Mellor, S., . . . Marick, B. (2001). Manifesto for Agile Software Development. Retrieved February 18, 2019, from Agile Alliance: http://agilemanifesto.org/
Kim, G., Behr, K., & Spafford, G. (2013). The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win. Retrieved February 18, 2019, from https://amazon.com/phoenix-project-devops-helping-business/dp/0988262592
Microsoft to acquire GitHub for $7.5 billion. (n.d.). Retrieved February 18, 2019, from https://news.microsoft.com/2018/06/04/microsoft-to-acquire-github-for-7-5-billion/