Management has asked that all teams move to a single Implementation of VSTS (Azure DevOps) and I have a couple of questions that I would like some clarity on.
Please let me know if this statement is accurate:
A single instance (Install) of VSTS can support multiple Projects.
If that is true
Can you roll up reporting from multiple projects or does it stop at the project barrier?
Can a Project support multiple work item templates?
I ask the second question because we have we have multiple teams that do different kinds of work, we would like to have a minimum set of fields for each work item type (Feature, Story, Task, Bug) but that set of fields would be different for the different teams.
using the example of a Task Template,
Can we have a "Base" set of fields that are common to all task templates but each team has additional fields that are unique to them?
Thanks
Kind of. Work item queries can cross Team Project boundaries. You can also use the OData API and make any kinds of queries you want in PowerBI. The built-in tooling pretty much assumes that reporting stops at the Team Project level, though.
No. A given project has a process template. It can change between versions of the process template (as long as they are derived from the same base).
So to answer your more specific question, let's say you choose the "Agile" template. You can create an inherited process template called "Agile Plus My Awesome Customizations" and add additional fields.
Then you can inherit from that and create process templates with additional fields for your individual teams.
So your process template inheritance structure might look like this:
Agile
Agile Plus My Awesome Customizations
Team A's Additional Awesome Customizations
Team B's Additional Awesome Customizations
Team C's Additional Awesome Customizations
However, each of those process templates would have to be applied to a different team project.
Related
***** I'm aware some of my terminology is also in the Django dictionary. None of what I write here is intending to use the Django meaning (templates, for example) *****
I am developing an application in Django that will be a customizable template driven data forms application (a project estimation tool that will allow a set of templates to be created and customized based on the type of project).
I want the application to provide a template editor, then regular users will estimate their work for the project/release by starting off from these templates. The templates would be quite simple; Maybe a dozen or so templates, each with categories and between 2 and 10 line items (tasks) per category where the users would enter their estimation information (hours, description, etc). It would also be great if the users were able to add custom fields for a unique feature that isn't part of the standard template.
I know how to make a rudimentary version of this from scratch fairly quickly, but given how many Django packages are out there, I figured there may be something to help me.
so, do you know of any packages that would help facilitate this or provide me a solid foundation for my project?
Thanks!
BW
Many of my project builds utilize the same stages, jobs and tasks over and over again. Is there any way to define a "template" plan and use it to make other templated plans from? I'm not talking about cloning, because with cloning, you are then able to make independent changes to all the clones.
What I want is a way to template, say, 10 different plans, and then if I want to add a new job/task to all of them, I would only need to change the template and that would ripple out into all the plans utilizing the template.
Is this possible, and if so, how?
That isn't currently possible, unfortunately:
A fairly old feature request for plan templates to reuse across projects (BAM-907) has been resolved as Fixed due to the introduction of plan branches in Bamboo 4.0 (see Using plan branches for details):
Plan Branches are a Bamboo Plan configuration that represent a branch in your version control system. They inherit all of the configuration defined by the parent Plan, except that instead of building against the repository's main line, they build against a specified branch. It is also worth noting that only users with edit access to the Plan can create Plan Branches that inherit from that plan.
While plan branches are a killer simplification for typical Git workflows around feature branches and pull requests indeed and might help accordingly, they neither fully cover the original request nor yours, presumably - that aspect is meanwhile tracked via Add possibility to create plan templates and choose a template when creating a plan (BAM-11380) and esp. Build and deployment templates (BAM-13600), with the latter featuring a somewhat promising comment from January 2014:
Thank you for reporting this issue. We've been thinking about templates a lot over the last few months. When we've got more news to share on this, we will be sure to update this ticket.
I know this question is closed, just wanted to add something I bumped into today:
https://ecosystem.atlassian.net/browse/PLATFORM-48
By the looks of this (issue in review at the time of this comment) we should be able to use templates for Bamboo plans pretty soon.
Edit 1: Rewrote question, including more relevant information
I've been reading a lot on creating django applications that do a single thing and can be easily reused in different projects separately from one another.
Essentially I have an administrative tracking project that manages both projects and placements. Both project management and placement management use similar data and therefor share a model. However both are independent of each other and may have uses in one project but not another. What would be the best way to organize these into different apps?
I've created an image with more details about the specific project in general including a simplified EER diagram, data types, and initial thoughts which can be found here: http://pasteboard.co/1weejc3V.jpg
Edit 2: Another thought...
Would creating a single management app which contains two sub-applications be a good way to do this? I.e. The management app hold the model which consists of the data that both placements and projects use. One sub application contains the functionality for placements, the other contains the functionality for projects. Is there any flaws with this idea, or simply better ways to go around it?
I have intended to have an app. where I want to have different things having relations with each other and want to know that whether I should have them as just different models or as differnt apps. Obviously if this is student, teacher in LMS then they are necessary component of LMS while if this is Job, Professional and Company then there can be different things associated with a job , a professional can have his full profile with different features, company can have different directory listing e.t.c. like features.
So Company and professionals who are users also should be as diff. apps. and job as different app.? Will this way be fine? as Jobs app. don't always everywhere need to have professional data or employer all data other than just name. So it seems like it is more convenient to have them as diff. apps, so that it can be used somewhere else.So is that right way?
Or
As I also want this project to be flexible so will the above make it more complex? And should I just treat them as diff. models instead of diff. apps. as Company and Professional are users , for which django gives Profile features also. So is this right way?
Which way is better one?
thanks in advance.
There is no exact answer here, so it's my opinion.
It is always good to have several apps rather than one big app. Reasons:
apps becomes smaller and it's easier to maintain small pieces of code;
project structure becomes more clear, I just need to look at the file manager to see main parts of the project;
interaction between apps become explicit: easy to test and prevent unnecessary coupling.
Not every Django app should be pluggable. It's ok to have two apps that depend on each other (if you aren't going to distribute them seperately). It's like having two dependent functions: nothing is wrong with it.
I've been using Redmine for almost a year to manage my startup. I have all issues stored in one project with two subprojects for areas that I had to outsource and didn't want to give the contractor access to the main project issues. My problem is that I have ended up with hundreds of issues which all vary greatly in the time required to implement them. Some are small e.g.'Fix bug in controller', 'Add telephone number to contact us page' etc and some require much more effort e.g. 'Create a new Q&A area', 'Migrate server to nginx', and some are more abstract e.g. 'Investigate new SEO opportunities', 'Consider implementing a reseller control panel' etc.
I feel like I must be using Redmine incorrectly as having these all mixed together is a bit confusing. Any ideas on how I could better organize would be greatly appreciated. If supplementing with other tools might be a better idea I'd love to hear suggestions.
I don't think there is a problem having all the issues you mentioned mixed together in a project as long as they're all related to the project.
The most important point when using redmine with projects having lots of issues is to make use of custom queries. This is a great feature, but in order to ba able to use it, you must also use and fill in other fields:
Tracker: Make use of different trackers (the default of bugs, features and tasks works for me)
Category: Can be a specific part of your software, or other aspects of your business (administration, IT/server, ...)
Version: Use the version to group different issues, usually used for a release, but can also be ideas or unplanned
Of course priority and Due Date - I often use them for ordering, but you may create a custom query of issues du in the next 2 weeks
Assignee is usually the most important if there is more than one user - first of all you'll want to see the issues assigned to you, as well as the issues created by you (in order to follow-up)
You can always add custom fields in case you have other information which may be used to filter your issues.
Once a set of custom queries are in place, you'll hardly consult all your open issues at once anymore.
Two little used features for redmine newbies are categories and custom fields.
Categories are usually used for modules in your project ("Database", "Front End", "Administration Panel", etc.) and you can use custom fields for anything else you find useful - i.e. Create a "Time Consumer (Estimated)" custom field as a list with "Whale (Weeks)", "Elephant (days)", "Tiger (Hours)", "Monkey (About an hour)", "Mouse (Minutes)".