Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
Azure DevOps Server 2019 Cookbook

You're reading from   Azure DevOps Server 2019 Cookbook Proven recipes to accelerate your DevOps journey with Azure DevOps Server 2019 (formerly TFS)

Arrow left icon
Product type Paperback
Published in May 2019
Publisher Packt
ISBN-13 9781788839259
Length 456 pages
Edition 2nd Edition
Languages
Tools
Concepts
Arrow right icon
Authors (3):
Arrow left icon
Tarun Arora Tarun Arora
Author Profile Icon Tarun Arora
Tarun Arora
Utkarsh Shigihalli Utkarsh Shigihalli
Author Profile Icon Utkarsh Shigihalli
Utkarsh Shigihalli
Tarun Arora Tarun Arora
Author Profile Icon Tarun Arora
Tarun Arora
Arrow right icon
View More author details
Toc

Table of Contents (10) Chapters Close

Preface 1. Planning and Tracking Work 2. Source Control Management FREE CHAPTER 3. Build and Release Agents 4. Continuous Integration and Build Automation 5. Continuous Testing 6. Continuous Deployments 7. Azure Artifacts and Dependency Management 8. Azure DevOps Extensions 9. Other Books You May Enjoy

Creating a team project for an Agile team

Azure DevOps Server provides a set of integrated tools that allow teams to effectively manage the life cycle of their software project. The team in Azure DevOps Server is encapsulated within the container of a team project. A team project is a logical container that's used to isolate all tools and artifacts associated with a software application in a single namespace.  

The conceptual boundary that was introduced through the team project eliminates the problem of having access to unrelated artifacts such as code, work items, or release information that isn't relevant to your application's development. Related team projects can be grouped together into a team project collection. Team project collections can be used to introduce a physical separation between a group of related team projects by hosting them in separate databases.

An instance of Azure DevOps Server is capable of supporting multiple team project collections, and each team project collection can internally host multiple team projects. A team project can house multiple teams. As illustrated in the following diagram, the process template is scoped at the team project level. Multiple team projects in a team project collection can use different process templates; however, multiple teams within a single team project will need to use the same process. Teams, however, have autonomy on the level of the backlogs they choose and the workflows on the Kanban board. The delivery framework of choice is applied through the Process Template, which, in turn, applies the delivery framework-specific terminology, artifacts, and workflows to the team project and all teams within the team project:

The process template defines the set of work item types, queries, and reports that can be used to plan and track the project. In this recipe, we'll learn how to create a new Team Project using the Scrum template.

TFS 2018 and later versions no longer support native integration with SharePoint products. If you're planning to upgrade to Azure DevOps Server 2019, read About SharePoint integration (https://docs.microsoft.com/en-us/azure/devops/report/sharepoint-dashboards/about-sharepoint-integration?view=azure-devops) to learn about the options available to you.

Getting ready

How to do it...

To create  a new team project from the web, follow these steps:

  1. Launch a browser and navigate to the Azure DevOps Server Portal.
  2. From the top right side, click the +Create project button:

  1. Provide a name for your new team project, select its initial source control type, and select a process to create a team project. The work item process is a one time choice and cannot be changed once set. See Choosing the right version control for your project (https://docs.microsoft.com/en-us/azure/devops/repos/tfvc/comparison-git-tfvc?view=azure-devops) and Choose a process (https://docs.microsoft.com/en-us/azure/devops/boards/work-items/guidance/choose-process?view=azure-devops) for guidance:

The ability to work from both Git and TFVC repositories from the same team project has been supported since TFS 2015 Update 1. See Git team projects (https://docs.microsoft.com/en-us/azure/devops/repos/git/team-projects?view=azure-devops) or TFVC team projects (https://docs.microsoft.com/en-us/azure/devops/repos/git/team-projects?view=azure-devops) for more information.

How it works... 

The following items are created for you as part of the team project creation process:

  • Dashboards: A canvas to bring key information radiators to raise visibility within and outside the team
  • Code: A code repository (Git/TFVC) based on your selection is provisioned
  • Work: All agile planning and tracking tools are nested under this hub. 
    • Team: A default team with the same name as the team project is provisioned.
    • Area Path: A default Area Path with the same name as the name of the Team is provisioned. The teams' backlog is configured to show work items assigned to this Area Path.
    • Iteration Path: The set of iterations is pre-created for the team.
    • Team Portal: The Team Portal allows the Team members to connect to TFS to manage source code and work items, and build and test efforts.
  • Build & Release: Automated pipelines to build and release your application
  • Test: Plan, track, and execute tests
  • Wiki: To share knowledge and documentation with the team

These are shown in the following screenshot:

Azure DevOps server simplifies navigation across the portal, and for those who prefer the keyboard to the mouse, there is a great support for navigation through the keyboard in both global and local hubs. Hold Shift + ? in the portal to see the full list of supported keyboard shortcuts.

There's more...

Azure DevOps Server makes the process of setting up a new team project very straightforward—so much so that you may be inclined to create a new team project for every software project. I would generally not recommend this; with support for multiple teams and backlog isolation at the team level, it is possible to have a logical separation, along with the ability to share within a team project. In principle, you should consider a team project for each product, and a team for each work stream. The only time you should consider splitting a product team out into a separate team project is if it needs to follow a unique process, since process templates are scoped at the team project rather than at the team level. 

If you find yourself organically needing to grow out into a new team project to use a different process template, you can consider leveraging the VSTS Migration Toolkit (https://nkdagility.com/vsts-sync-migration-tools/) to carry out a full fidelity migration. 

lock icon The rest of the chapter is locked
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at $19.99/month. Cancel anytime
Banner background image