At my company, we have a very small (<5) team. We build internal web applications of which we support about a dozen and expect to add more.
We are setting up TFS 2010 and wonder what the best structure is? We don't work concurrently on a project, so I think we don't need branching. But do we create all our solutions under one Team Project or create a new Team Project for each web application?
We also have a few class libraries shared in all the web applications. How do we manage this? I've Googled all day on it and just gotten more and more confused.
I've looked at the guidance but it all seems pointed towards more complicated scenarios with bigger teams working concurrently.
Looking forward to any help,
Richard
I think you will find branching useful even if you have a development team of one!
Being able to try out significant code changes and being able to merge them back to the main (trunk) code is great.
In terms of shared class library projects, you can actually add them to more than one solution at any given time.
Of course changes will only happen in that project, and therefore every solution that uses them will be affected. Therefore you should set up 'continuous integration' on your build server in order to check that other solutions are not adversely effected.
Related
We have TFS 2013, currently for the team project working we don't have any branches, basically just a plain folder structure with various solutions in them.
With the goal to introduce release management, the intention is to create several branche, e.g. development/main/releases
As I was told I cannot 'disturb' the project team developers from their day to day work since there are other projects being worked on, question, what is the best practice to do this? Create a separate team project? How can we adopt the branching practice without asking all the developers.
Please help point a direction for this or share some thought on this, any help is appreciated!!
Unfortunately to do this you'll have to "disturb" the development team. You have 2 options. 1. Come up with a process in isolation and then disturb them when it goes live. 2. Collaborate with them on a process and work together to meet your requirements. (Being able to release your code to production is a key requirement for any project, sadly it's so obvious that it never gets added to the backlog / project plan and is always treated as a afterthought)
I recommend option 2. Without collaboration you're just going to end up causing resentment that you're imposing something on the Devs and they'll fight it tooth and nail. Also without the development team being involved you'll miss something important that will make the process brittle and difficult to maintain.
You'll need to get buy in from the Developers to implement a branching strategy as it will have a significant impact on them, they need to understand why you're doing this and what the benefits are, both to them and the business. They don't necessarily have to do any of the work, but they need to know what you're doing and why, they will also need to know when the changes are coming so that they can plan for the change.
Firstly you need to real the ALM Rangers version control guidance.
Secondly you need to get the developers to read it as well. They will be responsible for maintaining the code and merging it between branches. They will need to know when and where they need to check in various changes (such as hotfixes), and what process they should follow when code is ready for release.
Finally, regarding your question about where the branches should be located. It would be better to locate the all branches in the same Team Project rather than having your Dev branch in a separate Team Project.
I have a project with 4 teams handling different parts of a fairly large web based system. What would be the best way of handling this in Jira and Jira Agile?
One project and board per team or is there another way of organizing this in Jira Agile?
Read about using components but since I'm fairly new to Jira Agile I don't know how to do that.
If many team are working on different part of the same system, I suggest you create only one project. From my experience there is a lot of chance you will want to move 'items' from one team to another or link two items that are related but not handle by the same team.
Like previous posts mentioned, GreenHopper is just an (agile) plugin that help you manage items in JIRA, allowing to display and manage them in different ways. The plugins is especially useful if your are following a development process like Scrum.
With the last version of the tools I was able to easily share a single 'backlog' of work to do between multiple teams and then 'assign' items to a specific team when it's time to work on it. When planning for the next Sprint, for example.
Of course having a clear view of your process is key.
I think you are confused about a few things, which is understandable for somebody new to the tool.
Jira is the software you are using and Greenhopper is an external company that produces plugins for it, mainly the Agile plugin. Components are within Jira and they are simply a way you can categorize your issues. I suggest you find a tutorial video on jira to introduce you better to the tool.
Now, again, these are just tools. They don't dictate how you should work. Jira is very flexible that way so you can do Agile, Scrum, Kanban or whatever methodology you want within it.
You need to first decide what methodology/process you will adopt. Basically, how will you guys work?
Are all the teams working in sprints? Do they have the same deadlines? Are the stories-issues parts of a whole or can each team deliver a full feature on it's own?
For example, if one team is infrastructure, one is UI and one is DB, their parts will likely come together to make a "whole" feature, that is complete and tested.
Another example is if team A is doing a Reporting Module and team B is doing a Login module, their features aren't usually related and they can work separately.
So basically, you can't ask anybody here to give you the straight answer. Stop focusing on the tool and understand how you will work and what makes sense for you.
And remember: agile is trial and error. Try something and if it doesn't work, adapt.
I am facing this ridiculous problem. I have more than 150 projects in tfs, and when i need to give admin rights to a particular person, or give portal rights, enable documents folder, change templates, get a combined report, etc, it gets tedious job to do it on all the projects...
Is anyone aware of such a tool that can work on multiple projects at a time ?
If you are looking to ease the pain of managing permissions across TFS, SharePoint, and SQL Reporting Services, then this tool on codeplex can help:
http://tfsadmin.codeplex.com/
I've not come across anything that allows you to do this, the only thing you can do really is to make use of those AD groups. If everything is organised into a decent structure (if not, move it :)) then the permissions should filter down, then it's just a matter of tweaking when needed.
Brian Harry's comments in response to Neil on Builds though: http://blogs.msdn.com/b/bharry/archive/2011/09/19/the-new-team-explorer-in-tfs-11.aspx imply that it's not going to be "fixed" (or significantly more awesome) next release though :(
Anyone have some good pointers on how to get multiple teams doing concurrent asp.net development using Microsoft TFS?
i have been using subversion for the past many years now and it allowed my team to work freely without exclusively locking files and doing auto merges when possible (like 99% of the time)
but this all falls apart when my new team is forced to use TFS with exclusive locks...
any thoughts?
i am trying to get three development teams working on a big project together and want to do it with branching so we don't over-write changes and work efficiently.
TFS can work without exclusive locks. Seriously. If you CAN work with it (as in: non-exclusive locks have their own share of problems), TFS will work like that.
For many scenarios, though, non-exclusive checkouts simply do not work (logically) because the merging is too complicated.
i am trying to get three development
teams working on a big project
together and want to do it with
branching so we dont over-write
changes and work efficiently.
Non answerable. Generally I would say this is total overkill, but it really depends on the scenario you work in and the langauge you develop in (example: easier to do with WPF than with WinForms). if you work on a website, then - it may be problematic. If you work on a large financial applicaiotn, you may not have too many people trying to check out the same files anyway.
This is totally depending on the context whith you do not provide.
I finally was able to complete the installation of TFS and started the creation of my first team project which introduced me to the process template.
After following to the link to Microsoft's site for process template information I was inundated with new information to consider. What templates have all of you had experience with that either worked out very well for you or were more of a stumbling block to the project? What were the biggest advantages and disadvantages you've encountered?
Some information about my project, I'm the lead developer for a small company and will be using TFS/VSTS to create an intranet portal to consolidate the end users day to day and increase automation to enhance productivity etc. It's entirely new development taking advantage of C#, ASP.NET and SQL Server 2008.
Ideally I'd like to take advantage of features to enhance collaboration with the stake holders to help add desired features and to track the status of development and offer feedback etc. I was also looking to take advantage of JetBrain's TeamCity for my TFS so if any specific template / software really adds cohesion between TFS, TeamCity, Developers, and Stakeholders that would be ideally what I'm interested in.
Are you already using a software development process like scrum? If yes you can try this Team Process Template over here.
How large is your project team and the project? Microsoft has published one of it's internal Process Templates (MPT) over here. You can get some guidiance and inspiration from this template.
As tangurena mentioned. People use the standard templates, change the bug a bit and store some documents there. I would recommend to keep the process 'light' as well.
However the process template isn't all.
Here are some ideas what I would do (in your case):
Create some high order workitems (features/stories) which stakeholdes can create (constraints and TFS user groups are your friend). They can then access their requested features via the TFS Work Item Web Access. That way you don't need a CAL for them
Create some reports which show planned work accodring to releases.
Setup the build automation and create Reports (a.k.a. Release Notes) from your workitems according to the builds.
What were the biggest advantages and disadvantages you've encountered?
Imho the biggest disadvantage is that you start believing that the template is your silver bullet. It's not, it's your starting point.
The TFS ecosystem offers you alot opportunities to create own bits of software that fit your needs. Just check out the TFS API.
Here is another nice agile-based template (original is on SSW, but you have to get around a login wall).
This template helps enhance cohesion between developers, managers, and other stakeholders by including more robust support for project process (documentation, reviews, &c., &c.). For example, there are types built in for process elements like release plans.
In general terms, I'd favour as small a process as you can manage. The more states, the more fields you have, the more likely the information in them is just plain wrong.
We're running with our own version on the Agile template. Most of what we did to it was delete stuff.
You can use the TFS API to log builds into the database, which should enable you to bridge TeamCity and TFS. Other than that, I'd probably just go with the web interface that comes with TFS, I don't think you need third party software for this.
K.I.S.S.! I created a custom work item based off the Agile one. And thats it, just one work item. There is a "System Severity" that IT uses and a "Business Priority" that the client/customer uses. There is also a "Request Type". With those three along with the built in Area and Iteration the entire team, including the clients can query the work items to get only the items they care about for the release they are concerned with (or all of them regardless of the release).
I did not modify the state machine much at all. This left us with something that is very flexible for everyone. Everything from blue sky requests to the mundane content/visual bugs can be logged there.
The client uses TFS Web Access (unlimited CAL) and the devs (me and 1 other) use VS. At my last job I created the same setup, the dev team was a team of 5 and it worked even better there! I was dev lead there as well and technical PM.
The biggest advantage was having a very flexible system for everyone, when using 1 work item type for everything. The disadvantage would be a learning curve for the client, but once they knew how to use it most like it. A suggestion would be to look into cheaper tools out there for a similar implementation, but, our .edu discount with MS cant be beat.
I would have to say that you must identify the system you will use for your company's SDLC first. The process template is merely a tool and without a good understanding of the underlying process it will not help and can make things more difficult. User adoption is crucial to the success of the SDLC and process template.
We use Scrum for Team System. We chose this due to our experience with Scrum as an SDLC methodology. There are several excellent books and articles on the web to help you get up to speed. Scrum will tie together the business stakeholders into the process.
In our system the Product Manager is in total charge of Product Backlog Items and works with myself and the CTO to prioritize them into Sprint Backlog Items.
The only change we have made to the process template was to add a "Failed Test" state and corresponding workflow.
It might not be the best template for you but I still wanted to mention it here: XP for Team System. It is basically a simplified version of MSF for Agile Software Development:
[...] it removes some of the setup tasks that an XP project will probably not want to undertake and changes the Work Item Type name Scenario to Story.