I recently inherited the management of a few legacy applications and the associated development team of 3. Currently, the team manages work visa emails. There is no central place to see all work. Some of the projects have their own VSTS sites.
I would like have a single/ unified intake process, work board. Is there a way to have a VSTS site sit on top of other VSTS sites to provide this view. Other option I can think of is to bring in these applications as separate repositories under a single VSTS site ( assuming VSTS allows this).
Anyone with prior experience, please suggest other ways to do it. Yes, I am stuck with VSTS - corporate standard
If you are using git in VSTS, then you can have multiple repositories.
This would be a good approach. https://blogs.msdn.microsoft.com/willy-peter_schaub/2014/11/19/many-git-repositories-but-one-team-project-to-rule-them-all/
Then you can create teams within the same team project to separate backlogs, sprints, kanbans for each team. See https://learn.microsoft.com/en-us/vsts/work/scale/multiple-teams?view=vsts
You will also be able to see a kanban/backlog for the full team and you could even use the Plans hub to group all your teams together in a unified view. See https://learn.microsoft.com/en-us/vsts/work/scale/review-team-plans?view=vsts and https://learn.microsoft.com/en-us/vsts/work/backlogs/backlogs-boards-plans?view=vsts
Related
I'm thinking to move to Azure DevOps. But I'm at the stage where it's hard to decide which option will be useful.
My Requirements:
Single dashboard for the current sprint to have transparency to
everyone in the team. No context switching.
Single backlog for all projects.
User stories & bug will be easily identified by project.
Reports by projects, teams, etc.
Service hooks - Microsoft teams, etc.
Source control - GIT.
Artifacts.
Test plans under one board.
I'm thinking of going with single project(multiple repositories)
But before going down this road I just want to know what are the pros and cons of both options.
In general, we recommend that you use a single project to support your organization or enterprise. A single project minimizes the maintenance of administrative tasks and supports the most optimized / full-flexibility cross-link object experience.
Even if you have many teams working on hundreds of different applications and software projects, you can most easily manage them within a single project. A project serves to isolate data stored within it. You can't easily move data from one project to another. When you move data from one project to another, you typically lose the history associated with that data.
So according to your situation, it is recommended to use a single project with multiple repos and multiple teams. For details you can refer to this official document.
Reasons to add another project
You may want to add another project in following instances:
To prohibit or manage access to the information contained within a
project to select groups
To support custom work tracking processes for specific business units
within your organization
To support entirely separate business units that have their own
administrative policies and administrators
To support testing customization activities or adding extensions
before rolling out changes to the working project
To support an Open Source Software (OSS) project
I am in an enterprise that creates many large to small scale applications. Way back when I started using Visual Studio Online/VSTS/now Azure devops I broke all of these apps out into different projects. However, now it seems there is good support for managing multiple apps in one project, and this seems easier from a management standpoint.
From the research I did it seems i can do each service individually:
Repos: Select Import Repository from the consolidated project and enter in the URL of the app i want to import BEWARE
Also, the system automatically resets the State and Reason fields to the default initial values for the work item type that you move.
and I skimmed over the docs and missed that snippet. oops
Boards: Go to query (optionally select query across project) and move all items to the consolidated project (creating the appropriate teams, areas and past sprints to keep history)
Builds: Export json from source projects and import to consolidated project
Releases: Same as Builds
(we do not use test plans or artifacts at the moment)
Doing it this way I probably will loose build and release history, which is probably not a big deal once enough time passes, but I did not find any other good way.
My two questions are:
Are there better guidelines to move entire projects to one project?
Will I permanently or temporary loose anything else besides the build and release history that I am not realizing?
I went through the same thing and had to do what you described. At the time there was no support for moving services/functions between Projects or Orgs at all, let alone consolidating into a single Project. Unless something's changed, short of automating via your own API scripting it's all manual.
The other watch outs were mainly around access and security:
External API integrations such as Web Apps, Function Apps, JIRA, Service Now
External inbound app authorisations
External outbound app authorisations such as Azure Service Principals
Variable Group authorisations to YAML Build Pipelines
Library reference updates including KeyVault
etc
This refactoring ended up being much more work than the platform consolidation itself.
(Posting the question here as this is the 'community' that Microsoft redirects to with a 'Need advice? Ask community' button. Hope it won't get closed as 'primarily opinion based' or 'too broad')
Hello,
I want to start using AzureDevops in my department for organizing code & work. We're a small team who creates a large number of applications & plugins.
Some of these applications have a very short lifecycle, i.e. we deliver them, and they work for years without changes. Other apps are larger and are updated/fixed across several months or years.
These applications are completely separate from each other in all aspects.
As far as I understand Azure DevOps structure, my department should become an 'Organization' (we can/need to be separate from the rest of the corporation).
I am a bit puzzled about the 'Project' part. Documentation says
In general, we recommend that you use a single project to support your organization or enterprise.
So, let's say we do have one project called Our Apps - where do we then put all the individual application-projects?
As far as I understand, each product (application) that we deliver should have it's own repository (or a set of applications, if they are logically connected).
This is in order to allow a developer to simply clone the repo on their machine and contribute to that product only - without downloading other projects etc.
I need to be able to:
easily navigate/see all the tens/(hundreds?) of applications that we create,
view their separate kanban boards (for those project that do have it, not all of them will)
to see their repositories (Git or TFS), commits etc
see & manage their pipelines
At the moment it seems to me that the only place where I can see a 'list' of what products do we have is the drop down below:
And the only way to see what is going on in the big-enough-to-get-own-board products is by creating a new separate 'SomeApp Team' in the Project (even though same people are in it), so that I can have a board for the SomeApp - and view the boards from here:
Is that the intended way to organize the structure?
Any alternative approaches?
Is there any way to have a 'cross-reposistory' or 'cross-team' overview?
What about creating documentation for each 'product'?
The "one project to rule them all" was coined by Martin Hinshelwood and his blog post from way-back-when explains the reasons and limitations.
With the introduction of Tagging and filtering on the backlog there is an alternative approach within the one-project setup.
Create team for the real teams you have in your organisation.
Create an area path for each major project/product in the org.
Assign the area paths of the projects to the teams who are working on them. This can change over time.
Optionally tag work items with the major project/product for additional filtering.
This way each team sees a complete view of all the work they can pull from. And they can quickly filter the work by tags to remove items from view when discussing specific projects/products.
Also, when teams change their focus from one product/project to another, you can simply change the assigned areas for that team to update their view.
The Plan View extension provides an additional cross-team view across over all the work. And the Dependency Tracker extension can visualize dependencies over time.
You can also use the Epic/Feature/PBI|UserStory tree structure to create additional grouping in your work items. You can customize the process template to introduce a Product level, though for the planning features to work, that would also mean that you'd also have to create full traceability from Product down to PBI|UserStory.
The main recommendation is to try a few of these approaches in a light-weight manner to see how they work and find your own ideal setup.
Another option for cross project visualization is to enable the Analytics Extension and connect it to PowerBI.
As you'll soon figure out, naming guidelines for your Tags, Repositories, Pipelines is going to be very important. Being able to quickly filter to the right level requires this.
Is it possible to share Deployment Groups across team projects in VS Team Services?
I have a few logically different team projects sharing the same servers. I would like to create one instance of deployment groups and share it across team projects
Currently, there is no way for this to span projects. In VSTS, very little spans projects for a variety of reasons such as security and pipeline management. Due to the way the pipeline works in VSTS, I don't think they will ever let this span multiple projects. You could always suggest it in the VSTS User Voice forum or get a more detailed explanation as to why not.
We have several closely related DevOps projects each with their own jazz git repositories in our Bluemix DevOps account. Each project has its own stories/tasks/defects etc.
What is the current best method to gain a single view of the cumulative backlogs of all projects so we can have one place to prioritize items and plan sprints across all projects. If DevOps Track and Plan can not do this. Is there a 3rd party tool that can integrate with DevOps/Bluemix that will do this for us?
Not a perfect solution, but I asked a very similar question and have had success using the approach described for several projects:
How to manage multiple components with IBM Bluemix Track & Plan
This isn't a supported capability at the moment.
I've passed your question on to DevOps Services' developers. We're adding features to Bluemix and Bluemix DevOps Services all the time.