My team is looking to migrate many of our tools (SCM, bug-tracking, builds, testing) to TFS. We're considering moving each system in stages. For example, move source control first, bug/feature tracking next, etc...
Since we have to choose a process template to use source control (or anything in TFS) how locked in are we with the decision? I'm looking to avoid having to create another project later (or is that not as bad as I think it would be?).
I know I can in theory customize everything the process template configures after the fact (right?), but how feasible is this in practice?
Here is how I see things happening:
We migrate our source code. We choose Microsoft's CMMI template.
We create a new work item (or check-in note) that is a simple link to our legacy bug tracking system.
We work for awhile.
We wait until the powers that be (we're a decent sized software company) to work out a new TFS development workflow. This may be a simple collection of new work items or an entirely new template that configures all sorts of stuff.
We try to migrate our TFS project to this new system without loosing our history.
Will we be sorry we didn't just wait until all these decisions were finalized before using TFS?
So, you are right to think about your process template as there is a certain amount of "lock-in" however it isn't too severe. It's like you are stuck to your process template with honey rather than super glue.
Personally, I would start with the MSF Agile template. It is much lighter weight and contains less work items - so you more likley to want to add things to it (very easy in TFS, very well supported) rather than take them away (more complicated and not entirely satisfactory).
However, if the power's that be decide to go down an uber process definition process and magically come up with a new process template in 12 months time that they want you to use then it isn't completely lost. If you find that you want to create a brand new Team project, as long as it is on that server (or Project Collection in TFS 2010) then you can either branch your code over to the new team project (which means that history is somewhat obscured in current versions of the TFS clients) or you can create a new Team Project with an empty folder for source control and then move the child folders over from the old team project to the new one. This will preserve history perfectly as TFS maintains history for moves on the same TFS instance. Your work items from before the move will be stuck over in the old process template though and you'll need to decide if you want to copy them or just leave them to get closed out naturally.
Obviously, by actually using TFS for 12 months on real projects, when the powers that be come knocking you are also going to be in a much better position to know what you want your shiny new process template to look like - and I've often found that this is an excercise that just never happens and most people are happy tinkering around the edges of MSF Agile or pick something more prescriptive like Scrum For Team System.
Hope that helps,
Martin.
Related
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 am looking quickly move changes between Salesforce Production & Sandbox. Is there any way we can know the difference between two environments i.e How many workflows, objects, email templates are modified/added in compared view.
I know we can use outbound change set but its tedious job of moving the changes and not feasible when Production is continuously being updated.
After speaking with the experts at two Dreamforce conferences I find the only way to get a description of an instance is to use the force.com IDE, as suggested by LaceySnr. I've learned a couple techniques that help.
First, I no longer even attempt to use change sets. These are time consuming to build, have no clarity as to what is really inside and sometimes just won't work.
Second, I keep at least two force.com IDE projects for each instance (test,production). The first project has everything (check everything in the metadata component). The second project is tiny and only has the components I want to work on.
The first project is checked into some change control system; CVS, SVN, Git, Mercurial, etc. Your choice. Using the differencing tools on this project let's you compare change sets.
But it is nearly impossible to develop using the first project because it takes too long for force.com to process even the smallest change. This is because it processes the entire project whenever any change is made. So, make all the code changes in the smaller project.
Then look at the ANT build tools http://www.salesforce.com/us/developer/docs/apexcode/Content/apex_deploying_ant.htm to automate the migration of changes from the smaller to larger project.
I've not done this with workflows, but it is a method I use for code, layouts and objects: Use the force.com IDE from http://developer.force.com to setup projects for both Sandbox and Production, being sure to select all of the metadata components that you want (you'll want to include workflows for instance).
This will leave you with the contents of your projects stored inside a project directory in the IDE's workspace directory, then you can easily use a diff tool (I use the free DiffMerge on Mac) to compare the directories, and of course drill down into files to see what changes exist.
we recently decided to move to TFS 2010. we would like also to improve our source control structure and projects structure.
here is the structure the team agreed on:
|OurCompanyName (or common root name)
|
+--Windows
+----Applications
+------App1
+------App2
+----Services
+------WindowsService1
+------WindowsService2
|
+--Web
+----Applications
+------WebApp1
+------WebApp2
+----Services
+------WebService1
+------WebService2
|
+--Common
+----ThirdParty
+----Libs
+------DataAccessLib
+------BusinessLogicLib
|
+--Tests
+----TestProject1
+----TestProject1
The common folder holds 3rd party and our in-house libraries which is used all-over(App1,App2,WebApp1...etc)
We need to acheive the following :
Release versions must depend on latest production release of Libs.
if tests failed, depended projects shouldn't build and team should be notified.
simple branching: development, production,versioned releases and how we can structure them accordingly.
I have already read the following guide Visual Studio TFS Branching Guide 2010 but it only addresses the branching bit of it.
You aren't really asking a question from what I can tell. But I can give some feedback/discussion on your goals.
Release versions must depend on latest production release of Libs.
A release version should depend on whatever it used while it was being developed. Not whatever the current version is. You may want to go into more depth on what this requirement is and why you think you need it.
if tests failed, depended projects shouldn't build and team should be notified.
TFS doesn't support chaining builds out of the box, you can modify the build template to add support, but it's not a particularly clean solution (imo).
You can self subscribe to failing builds utilising the built in tfs alerts subscriptions, however it is up to each developer to do so. (Unless you subscribe a mailing group or create a custom event mailer).
Again why are you automatically updating dependencies in other projects? surely you'd be better off using a pull for updates than a push and use a technology like NuGet to handle your references.
simple branching: development, production,versioned releases and how we can structure them accordingly.
That sounds like simply branching each time you do a release, which is very simple.
If you however knew which changeset you releases you wouldn't have to branch and could branch only if you needed it (eg to fix a production bug). It takes a lot more work as you either need to manually label your code on release (at which point you gain nothing over branching) or have an automated release process which does it for you.
Other notes
You dont' want to use multiple Team Project Collections - this adds in a nightmare when it comes to managing build servers.
You may want to update your diagram to show what is a Team Project, Branch, and what is just a standard folder.
Having used TFS for a while, I would like to give a caution:
You look at things from the developer's side, as we did when we started thinking about how to best deploy the projects. However, you should also take under account project management requirements.
Having different TFS projects, means different reporting data to the manager.
Thus if App1 and WebApp1 are to the person that runs your projects part of the same overall project, then if you have them in different TFS projects, questions of the form: 'How many hours did my team spend on this project' will be difficult to answer.
I would seriously look into this issue before deciding on the project structure.
Now regarding your questions:
Release versions must depend on latest production release of Libs
As Betty (above) mentions this is not good practive. What will happen if development took place with production release of Lib v1.0 and sometime during stabilization Lib changed to v2.0 ?
if tests failed, depended projects shouldn't build and team should be notified.
I believe this is a matter of your build script, not of your layout
-simple branching
We try to implement a simple MAIN-line based approach,where we have one or more development branches (depends really on your specific requirements).
Once in a while, when dev code is considered 'stable' i.e. passed basic unit tests, it is merged onto the MAIN line. Developers carry on, on their development branches whereas code on the MAIN line goes more extensive testing. Bugs found are reported and fixed initially on the DEV branches and merged back onto the main line. Once code on the MAIN line is good enough, stabilization starts on a RELEASE branch. After that point, bugfixes take place on the RELEASE branch and merged back into the MAIN line. Note that 'stable', 'good enough' are values that mean different things to organizations.
Context: I'm currently working as an intern at a company which has made the move to TFS 2010 from VSS. TFS has been in use here for a couple of months now, but in the early period after the move some 'mistakes' were made in setting up the projects. After while the need for a custom team project template was recognized. The template has been developed and is now being introduced into the organisation. (small web development company, many small projects)
Question:
We're trying to migrate old projects to the new template by setting up new pojects with the custom template. We'd like to move the sources of the old projects into projects making use of the new template. The history of the sources should be preserved for support reasons. It is undesireable for the old projects to appear in the Team Collections' Team Projects list, so we'd like to hide them if deletion is not an option. (to reduce the garbage in the list)
I have some solutions on my mind to get the job done, but I'm unsure if they'll work out. (even after spending some time researching the issue on the web)
1: Doing a branch from the old project into the new and then deleting the old project. I think it should keep the history of the the old project has been deleted. Some people over here are very vocal about this not being the case causing some strife. Before pushing this option I'd like to be sure this will work
2: Hijack the migration tool to migrate sources between projects (possibly via via a temporary Team Collection). I have read this could be an option, but the details of how to execute such a move are still unclear to me. It seems this has a lot of caveats attached to it and can be cumbersome to execute. (I'm no superman when it come to these matters, but so is noone else over here)
The Migration guide seems to suggest that this might be possible, but I can't determine if this scenario is supported, and how to recover if things go wrong.
Maybe it is possible to set up the new projects and hide the old projects from the team collections' team projects list without deleting them? (I wonder if there is some kind of inactive setting for team projects, I can't seem to find any such option after exploring the tfsconfig tool of the admin console)
An explanation of how to best apporach this problem and possible solutions would be much appreaciated.
Doing a branch from the old project
into the new and then deleting the old
project. I think it should keep the
history of the the old project has
been deleted.
I'm pretty sure if the old team project is deleted, the part of history that is associated with that team project will also be gone, see here for more details. You can confirm this by doing a quick test move if you want.
Maybe it is possible to set up the new
projects and hide the old projects
from the team collections' team
projects list without deleting them?
You can mostly achieve this by denying read access (GenericRead) to most of the users on the old team projects. Of course for the Project Collection Administrators who have this permission by default on all the team projects, the old team projects still appear in the list for them.
Good luck!
There is no firm relationship between a team project and a particular part of the source control tree. Let's say you have a team project named "Mistake". You have source at "$/Mistake". You can now create a new team project named "Got It Right", and specify to use the sources at "$/Mistake".
Use the source control explorer to move a solution between projects. Here is how the projects and solutions appear before moving a solution.
The move selection is found by either
right-clicking the solution, choosing Move from the drop-down menu
Selecting Move from the Source Control menu found under File in the drop down menu
I have a client who is using one TFS project just for source control only and now wants to manage work items in a totally different TFS project, using a different process template, and intends to link changesets to work items across TFS projects.
I know that this is possible in TFS, but don't know what the limitations or issues that come with this configuration. e.g Build Summaries, Reporting, etc.
I would prefer branching the code into a new TFS project and managing code and work items together in one project, but need to know how the above method stacks up.
It'll work - I've occasionally had to associate checkins with work items from other projects. I haven't noticed any issues with reports or the like, that said this seems like an overly complex arrangement with little benefit.
Seems like a strange set-up to me. While it will work, TFS is designed for the check-ins and work items to be in the same team project so you won't really get the full benefit of the TFS features. Does the client know that they can modify the process template of the existing team project or do what you say and branch or even just move the source into a new team project.
We used this model to allow us to have separate projects but against the same source branch. It worked for a while but once we started being more adventurous with branches the model broke down. So as others have noted, there's no reason why technically you can't do this, it's not standard.