My questions are listed at the end of this post but reading the background info first will help understand the context of the questions.
Background
I've had some limited experience working with TFS (on-premise) as a development team member in the past, and I'm generally familiar with the basic concepts. But now I'm also tasked with administering a VSTS instance (cloud). Most of my experience using TFS was centered around the project management features (backlogs, sprints, work items, etc.).
I'm rolling out VSTS in 2 phases. The first phase focuses on the non-technical project management aspects of the configuration. The second phase will focus on technical aspects such as managing source code and other development artifacts. I have some experience working with the source control aspects using TFVC repository, but no experience with Git repository.
I completed the preliminary design of the basic configuration (Teams, Area Path, Iteration Path, etc.) for VSTS. I suspect that my Area Path will need adjustment at some point in the near future. From what I've read, VSTS does a decent job of automatically updating Work Items (e.g. Features, Product Backlog Items, Tasks, etc.) when changes to the Area Path are made.
Questions
What I'd like to know is how other technical areas of the product (e.g. code repositories, build definitions, etc.) are affected when changes are made to Area Path. For example, if I inserted a completely new node somewhere within the Area Path, how badly will that "break" existing VSTS functionality (and what type of functionality will be broken and require manual repair)?
This is an easy one:
Area paths only affect work item tracking. Period.
Related
I did a check if this has been asked before but the closest I found were questions around a single application with different branches for clients.
What is the best strategy for handling multiple applications in version control? Say I have 5 completely separate applications that can require changes at any point. Do I put them all under the same main trunk (origin/master if you will) then branch off as required or should they all get their own trunk?
Let me know if it's not described well and I can add more information.
You should see the Branch strategically:
When should the team add a branch?
You should create branches in the following situations:
When you must release code on a different schedule/cycle than the
existing branches.
When your code requires a different branch policy. If you create a
new branch that has the new policy, you can add strategic value to
your project.
When functionality is released to a customer and your team plans to
make changes that do not affect the planned release cycle.
You should not create a branching for each user story because it
creates a high integration cost. Although makes branching easy, the
overhead of managing branches can become significant if you have many
branches.
In you scenario, It's based on how do you want to manage the applications, different schedule/cycle ... then you need to track in another branch as David mentioned above. And if the size of applications are very large, you can even version control them separately in new team project.
This article for your reference : Branching and Merging: Ten Pretty-Good Practices
Trying to figure out best way to setup Jira for cross-organizational project. We have a Continuous Delivery Program that will split off into separate backlogs to be worked by different teams based on Themes.
Wondering if we should setup one project to manage the overall high level project, and then different projects per theme of work that will be managed by the individual teams.
Are there ways multiple teams can work out of the same project but track their work separately (including if their work is Kan-Ban, Scrum-Ban or Sprint based?)
Regarding the question in the title. It's possible to move issues in JIRA from project to project. This feature is quite handy and you even can do bulk operations. See Moving an issue for more details.
Regarding structuring your projects. Out of the box there is no feature in JIRA to create such a workflow with projects and sub projects you have described.
A possible workaround could be using components as sub projects.
In this case you would create a project which act as your high level project and divide this project into several components. For components you can add a lead, do versioning but you can not set security permissions based on components for example. So this is not a perfect solution and have indeed some limitations since components are not projects. But you have to evaluate this approach by yourself if it is sufficient for you.
Another option would be to use a plugin e.g. Structure. I am pretty sure there are even more out there which promising to solve your problem. From my experience also using a plugin may be not the silver bullet you are expect. You have to evaluate it first if it really suits your workflow.
For the scenario you describe, the issues that you start from are probably more high-level than the actual work that has to picked up in the separate teams.
What I find to work well, is to keep 1 project (ie. Opportunity Backlog) for the high level issue (ie. an Opportunity) and when an opportunity gets detailed out, just create issues in the projects of the teams that will work on them. You can still link those issues to the opportunity so people who look at it can see what is happening in each team.
Another option is to keep everything in 1 project, but to make the relevant issues show up on the board for the team that has to work on them. A board can list issues of multiple projects. You just need to update the JQL query for the board accordingly. For more details, check the documentation. Note that working with sprints can get cumbersome if the same issues are listed on boards of multiple teams though. Best to configure things such that an issue is only displayed on the board of 1 team.
I wouldn't bother with moving issues too much. It's not a very user friendly action.
Having recently migrated to TFS 2010 I was wondering what the best or most widely accepted definition or configuration is for an Area?
The only useful article I can find online is this one and is what I would have assumed to be correct. However it got me thinking if any of the following is indeed more widely accepted.
Areas by business functionality
Areas by technology
Areas by system layer
Areas by physical or geographical location
It really depends on the product/project you 're building, I suppose it was made available as a general-purpose placeholder which can get its meaning from the context of the team & the team mission.I can imagine projects, where ignoring it on the grand total, would also be a perfectly acceptable solution.Our initial TeamProject structure in fact did ignore Areas for our flagship product we construct in a Team Collection. This resulted in a reporting nightmare, since we needed it on a platform-level (TeamCollection), rather than a distinct part of it (Team Project). When we realized the problem, we went searching & found this article, which made us change course: we are now using TFS Areas within one single Team Project & found what fitted best to our situation. In our universe Area = a distinct release line within the platform.
Areas in my opinion is a grouping mechanism, with Areas you can group your wortitems in any kind you want.
I think everything which fits to your development process and or make you more productive is ok.
All of your items on the list are valid types of areas, I saw all of them in projects.
But too deep hierarchies are not really helpfull, because if you create a workitem you than you have to choose/select the right area.
My company started using JIRA for issue tracking two years ago, and we have struggled with optimizing the workflow for it since. The main problem is that we have a number of modules and libraries that are shared between different products, whereas JIRA has a "silo" view of projects. Basically, JIRA is fine for tracking issues from a "customer project" point of view, but I started to see it as more and more useless for a "back-end development" point of view.
JIRA's components are not good enough for my needs, since the developer of the module or library cannot correlate the issues appearing in different projects for her module and assign them to different versions of it. What I need is a hierarchy of projects, where a component in a higher (product) level project relates to another project at a lower (module) level.
Atlassian seems to be unwilling (unable?) to add such a feature to JIRA, despite numerous related issues dating back up to nine years. Moving to another issue tracking software that has this feature (if there exists any) is not feasible for us at the moment, though.
Judging from the number of replies on the related issues in Atlassian's JIRA system, we can't be the only company with this problem, so I would like to know what other people are doing to get around it.
My current plan is to use components for the product projects, and automatically create and link clones of component issues in the relevant module/library project. Clones are sub-optimal, since they are not as strongly linked to the original as I would like, and they double the number of issues in the system (or more, if the issue in the module project needs to be duplicated in other higher projects, say, if the fix would break the API or if it was a critical issue that any user of the library should be warned about), but I'd like to keep the original, since after fixing it in the module and closing the module issue, there'd be more time needed for integrating the fixed module into the product.
I have found plugins that allow post-functions on transitions, e.g. "CustomWare JIRA Utilities", so that should work for automated cloning, linking, and updating, although I am not 100% sure.
What is missing, though, is a good way to manage the dependencies between the different versions of products and modules (i.e., version X.Y of product A uses version I.J of library B), since versioned components are another thing that JIRA doesn't do.
Any better ideas?
I would treat reusable components the same way they're treated for distribution (e.g. DLLs), as separate projects in Jira.
Track your issues against the affected version of the module. You can always move an issue between projects if it's discovered to be a different part.
This won't help maintain cross project mapping (I.e. System A v1.3 requires Component B v2.7) but it becomes simple enough to dump in a Wiki.
Another approach is to create your own multiselect custom field, make it valid across multiple JIRA projects and use that instead of the system components field. You would lose the ability to automatically assign issues but gain the ability to use "components" that are valid in more than one project.
~Matt
OnTime uses a tree-based structure for projects, allowing you to open a filter to view descendents as if they were on the current branch. I don't know if that is much help for you.
I am pretty new to TFS and source control. I unable to understand the advantage of branching. Since i can do the same stuff by creating 2 folder main and development, when I am done with development.I can merge the code using any diff tool with the main branch.
Then whats the point of having branches ? I know there must a huge advantage but i am unable to understand.
(UPDATE: TFS now supports git for version control so the rest of this answer no longer applies)
I would google branch-per-feature.
The main advantage of branching is that you can work on a feature and not be interrupted by anyone else's work. When you are ready, you can merge and see if many features work well together or not. This is usually done as the feature is developed but for small features can be done once the feature is complete.
The advantage is that you have a clear history of what you did to implement something. Without branches, you would have a whole lot of commits mixed together with other features' commits. If QA does not pass a certain feature, you have your work cut out for you to put together another build using just the commits for the other features. The other alternative is to try and fix your feature so that QA passes. This may not be doable on a Friday afternoon.
Feature toggles are another way to omit work but this increases the complexity of code and the toggles may themselves have bugs in them. This is something to be very weary of and see how this became an "acceptable" work-around.
Branches are also used to track changes to multiple versions of releases. Products that are consumed by multiple customers may be in a situation that one set of customers is using 1.0 of the product while others are already on 2.0. If you support both, you should track changes to each by branches that are designated to them. The previous points still apply to developing for these branches.
Having said that, TFS is not ideal at branch-per-feature for a number of reasons. The biggest is that it does not support 3-way merges - it only has what is called a baseless merge. The way history is tracked, TFS cannot show you a common ancestor between the feature branch and where you are trying to merge it to. This leaves you potentially solving a lot of conflicts. In general, a lot of people that use TFS shy away from branching for this reason.
3-way merges are great because they will show you what the common ancestor is, what your changes are and what the changes in the other branch are. This will allow you to make a very educated decision on how to resolve a conflict.
If you have to use TFS, I would suggest using git-tfs to be able to take advantage of 3-way merges and many other features. Some of them include: rerere, rebasing, disconnected model, local history, bisect, and many many more.
Rebase is very useful as it allows you to alter a feature to be based off of another starting point, omit commits, squash commits together, split commits, etc. Once ready you can them merge into an integration or release branch, depending on the workflow you decide upon.
Mercurial is also another one that may be easier to use, but will not be as powerful in the long run.
If you have the opportunity, I would highly recommend moving away from TFS for source control due to a lot of limitations when compared to modern day DVCS.
Here is a nice set of guidelines to follow if you want to effectively manage branching/merging:
http://dymitruk.com/blog/2012/02/05/branch-per-feature/
Hope this helps.
There is a lot of information to read through, but there is TFS Branching Guidance located here if it helps at all - http://tfsbranchingguideiii.codeplex.com/