Management would like to migrate all teams using Azure DevOps (VSTS) to a single project to make reporting and work roll-ups easier. if this is done can the individual teams still utilize templates customized to their specific needs or would they need to use the default template for the project.
Thanks
We are being asked to migrate to a "standard" company project but don't know if we will be able to have customization for our process
No. One team project has one process template. You can customize that process template however you wish, of course.
What you could do is create an inherited process in order to make your customizations, and change every Team Project to that Process.
You have to take into account that the customizations you have made to your Team Project could be affected when you change to a inherited process.
Test carefully with some test Team Projects before.
Related
Since the process of one A/B test usually takes multiple sprints I would like to add another board in which I can add the A/B tests (as F.E. features). User stories for one sprint can then be added to a specific sprint for my team (which consists of a few specialists and a developer). This way I am able to overview the status (research phase, test , code writing, running, analysis, etc.) of all tests in one overview. I have not been able to find out how this is possiblie within Azure Devops, or if there is a work around. Can anyone help me?
My team also works in projects other than A/B tests, which means we cannot use the boards section.
Unless there is a hidden way to add another board to a team?
You could Copy or clone a work item to add the user stories or tests to a new boards. Open the user story you want to clone, then click Create copy of work item and choose whether to include exist links, attachments and child work items. After creating, change the Area and Iteration to your target boards.
Update
In Azure DevOps you can only create boards by creating a team. The team board is created as a side-effect of creating the team. Please refer to Manage and configure team tools and Configure and customize Azure Boardsfor details.
After creating and configuring a new team, you could see the boards in the dropdown list.
I have problem with configuration of AzureDevOps process.
My goal is simply automate work items - when work item changes state to done or is in state done on certain board I want to transfer it on other board.
I tried to achieve this by applying custom rules in my organization. Example:
I navigate to Organization Settings, select Process then I select process from list (is inherited from Scrum parent). Then I select bug (for example) and go to rules tab.
Here is screen of my configuration
Both Board no.1 and Board no.2 exist as Team Projects. I've added clearing assign to field and this one works properly.
I wondering if there is much easier way to automate moving work items through boards or team projects on status change.
I wondering if there is much easier way to automate moving work items
through boards or team projects on status change.
For this issue, I am afraid there is no easier way to achieve this requirement. Azure Devops has provided a built-in custom rule function to achieve this. This is already a very easy way.
In addition, we can also achieve this through the azure logic app, but this needs to be set in the azure portal. I don’t think it will be more convenient than custom rules.
To move work items to another project, you must be a member of the Project Administrators group or be granted explicit permissions to move work items.
New to VSTS, but not Git. Our small team has the usual mix of web apps, windows apps, other misc applications/services and we keep our database objects in visual studio sql server projects as well. So there are 15-20 or so different sets of code to deal with. Currently, each would have its own Git repo.
Was reading this post regarding single vs multiple "Team Projects".
Then, I posted this earlier but was specific to backlog items, but I suppose my real question was about the bigger picture regarding the idea of a "team project"
What would be a good structure for a small team with this number of applications. Assuming each application generally is worked on independently, but you might want to build 2 or more of these applications together.
How about one team project. Multiple "teams", one per "application".
Its the terminology that is throwing me off.
Can different teams each use a different repo?
Can each team have a different set of build definitions? eg. dev/prod etc
A team project is a container for a portfolio of related applications. A team project can contain one or more source code repos (Git/TFVC), builds, releases, test cases, work items, etc. All of these entities have ways of defining security around who can view/modify them.
A team is just an organizational structure within a team project. You can use security permissions to limit certain repos, builds (or build folders), etc to a certain team.
The generally accepted guidance is to keep everything in a single team project. There are lots of things that don't cross team project boundaries, such as repos. Work-arounds usually exist, but they are typically awkward.
The one requirement you gave ([we] might want to build 2 or more of these applications together) is actually slightly tricky regardless of whether the repos are in one or in multiple team projects -- a build definition can be hooked up to a single repo. If you need to bring in additional repos, you'll need to use submodules or add an extra build step to clone the second repo. I can almost guarantee it'll be easier if everything is in the same team project, though.
The one-word answer to the two direct questions you asked is "Yes."
How you set up your structure is really depending. There are many ways to organize it. Single repo, multiple repos.
If you are using CI builds, have in mind that the get sources task in your build will download your full repo. So if you have a single repo strategy your build could take longer to run. In this scenario you would also have more work to setup your builds and specify path filters to trigger only the correct build on your CI process.
Can different teams each use a different repo?
Yes they can.
You can create a security group for each team.
Then, on you team you can remove it from Contributos and add your new group as part of Member of:
After that, in your version control settings, add your new security group and remove or deny access to Contributos security group. This way, only your team security group will have access to the repo.
This is optional. You only need to do it if you want to isolate access to your repos.
Can each team have a different set of build definitions? eg. dev/prod
etc
You can setup a build for each of your repos.
If you need to isolate who has access, you can do it by changing the security on each build, removing contributos and adding your security group.
My team is currently using the CMMI board in Team Services and we would like to switch to the Agile board. I was told we can't just change the template, but I can't figure out how to export all of our open tickets to a new board. How do I easily change our team's board. Thanks!
At the moment this is technically not possible. When you choose a Process, during project creation, you can't change it to a new parent later. So you pick CMMI, or Agile or Scrum and later you can only change to a derived template.
What you can do though, is create an inherited process template and customize it until it looks and feels the same as another process template. It's quite a bit of work, but doable.
It is expected that changing from one base template to another will be added somewhere in the future. But at the moment it's not showing up on the TFS/VSTS feature timeline.
There is no easy import/export option either, though there are a few tools, like VSTS Sync Migration Tool that can copy over work items and map them to a new structure. I'll probably just be as much work as creating an inhertited process though.
I work in a large organisation which has many VSTS online projects.
We want to create a custom VSTS online extension and only enable it for selected projects.
I would like to create a Hub extension to make use of the full screen.
The only way I can think of is by creating it as a Dashboard Widget, but this restricts me to a small ui.
No, there isn’t the feature to restrict projects for VSTS extension. I submit a user voice here: VSTS extension project restrict.
The workaround is that you can get current team project by using VSS.getWebContext().project, then just display content for corresponding projects. (Note: Can’t set projects dynamically)