In a number of team projects I've worked on over the past year, we have chosen the Telerik OpenAccess ORM as the tool to manage our database model. We also use TFS as our version control software
I've ran into a number of difficulties using the Telerik product (which I'll save for another day), but one of the biggest issues is when multiple team members attempt to work on the model simultaneously, and try to commit their changes to TFS. The models generated by Telerik are difficult to merge and any conflicts will, more often than not, lead to time lost fixing the entity model. The only practical way to avoid these difficulties seems to be to implement a "relay" system, where only one person at a time can work with the model; something that isn't practical in a team development environment.
Has anyone found a way to use the two tools harmoniously?
This will always be an issue when working with similar models, even the model used by the Entity Framework.
You could always switch to Code Only mappings though. Then all of the mapping for your project will be simple, merge-able code files. link
Related
We are investigate how to using modern code version systems for a legacy systems.
However, there are some difficulties that we do not really know how to solve. How do you think we should going to organize this?
Some parts of the code we have responsibility for, and some parts the customer are responsibility for.
The code that is in our development system is the master, and all changes are made there and then sent out to the customer. So far is it like a common project. But for some directories with a few hundred files, the client is responsible for the code. Customer can change these files as they want, and do not have inform us. When we do an update for them, we need to get a copy of these files and merge our changes before we give the new version to the customer.
We have released 4 base versions of the system over the 25 years the system have lived. Our six customers, however, use different versions of the system, which means that we have to consider it. In addition, each customer has their own requirements, and we have made major adjustments for each customer.
We have several parallel projects related to the same files. Today we have major problems that the various projects interfere with each other, so we will benefit greatly from having changes in different branches. But how do we organize this?
Some projects affect only one customer, other projects involving several customers. And some projects may be introduced into a new future base version.
So my question is how to organize this in our new version system.
Background
According to the Visual Studio ALM Rangers, there are two major approaches to sharing resources (e.g. common libraries which are used in many separate products) in TFS 2012:
Workspace mapping, setting up workspaces so that they point to the appropriate version of each required library and product.
Shared folders, using branch/merge to get and update the shared resource
At a glance, shared folders seems like the way to go, but a client that I am working with has experienced a lot of problems with that approach in Starteam, and is reluctant to try it again in TFS. I am currently in the process of assisting the client migrating from Starteam to TFS.
I have listed pros and cons with each approach, but I am uncertain if I have missed something.
Workspace mapping:
Simple to setup and understand
Easy to test a library change in several products
Easy to get latest changes in a library, and to submit changes to a library
No tracability, or at least less tracability, e.g. if a change in a library was introduced in Product A, how to track that change in Product B
Changes in libraries may affect products in an uncontrolled manner
Build gets more complicated
Each user must set up his/her workspace individually (but there are workspace templates in TFS 2012 Power Tools)
Folder mapping:
Everything that is needed is configured in a given branch
Isolation between products and branches
Builds are simplified
More control of changes
Requires more disk space
Requires more administration in the form of branching/merging and setup of branches
One particular problem is how to test library changes in several products. As I understand that would require testing in product A, then reverse integrate to library and forward integrate to product B, then test that product and so on.
Conclusion, and final question
The client has successfully used something similar to workspace mapping in Starteam for 10 years, and plan to continue to use that approach in TFS. Although they have the problem to keep track of library changes that affects several products.
They are afraid that folder sharing will get messy and complicated.
My question is, have I missed something in my list above? Are there more reasons for why an organisation not should use workspace mapping, or for why they should use folder sharing.
Background: I'm using jira for bug tracking, and git for source control. I've got a complete end-to-end system comprising of an iOS front end, and a Java/Tomcat back end that provides web services and a GUI. Right now I've got a single git repository holding all the software and a single jira project tracking issues for the whole system.
Now that the software is live, I'm finding that changes are being made to either the iOS application or the server, but generally not both. The version numbers of the two components have diverged somewhat.
It's probably too late for this project, but in future:
Should I pursue the path of having all related components in a single source repository and tracked using a single bug-tracking project; or
Should each component be in a separate repository and be managed by a separate bug-tracking project?
I can see pro's and con's for both approaches, and I can also see that the answer could easily be "it depends".
Which way would you lean, and why?
I'd go with distinct source repositories for a few reasons
The developers working on the two are likely to have distinct
skill sets. Also, you may have management reasons for wanting to
segregate who sees what.
They should not be tightly tied at a protocol level - different versions need to interact.
The first point becomes even more important when you do another front end
The second reason is my main one.
However, I'd go with a common bug database. Defects/features may need changes on both ends. Also, it is extremely likely you will have bugs that are believed to be in one component but actually end up fixed in the other. If you try to migrate across databases, information will get lost. I've seen that too many times.
Our small development shop is looking to migrate our projects from VSS to TFS, and we're evaluating TFS vs. others (haven't pulled the trigger quite yet). The nature of our software shop is such that we have 100+ projects in VSS ranging from small one-man-show projects to massive enterprise-wide applications.
We are trying to determine how to structure our projects in the transition and have, for the most part, decided on putting everything into one project site/system with each project having a subfolder off the root.
With this type of setup, we are concerned that we will lose a lot of the functionality that TFS provides (bug tracking, scrum burndowns, reporting, document storage etc.) because all the projects will be in the same portal/project space and it will be difficult to separate out individual project tickets/items.
Does anyone have experience with this? What was your solution? Did you stick with TFS?
The answer to this question requires some planning on your part: how you intend to use TFS, and which of those capabilities has inherent limitations in the product. I would summarize my advice as:
You will need [at least] 1 team project per process template. That is, if two teams want to adopt / customize different processes, they will need to be separated.
Once condition #1 is satisfied, you probably don't need as many separate Team Projects as you think. 90% of TFS features & settings are hierarchical in nature, allowing you to scope them as broadly or narrowly as each of your projects requires.
For complete details, see:
http://www.codeplex.com/BranchingGuidance/Wiki/View.aspx?title=Guidance%20for%20Structuring%20Team%20Projects
http://blogs.msdn.com/richardb/archive/2007/05/01/tfs-team-project-whitepaper.aspx
http://msdn2.microsoft.com/en-us/library/aa974183(vs.80).aspx
The approach I've taken was to have a TFS project for each logical grouping of assemblies -- So we've a framework project that contains assemblies common to all our applicaitons, we then have a separate project for our quotations system, another for the costing system and so forth. Whilst the workspace mappings get a bit "interesting", it does allow different design methodologies for different projects, and at different timescales -- so one team might be half way through a sprint (Most projects use Scrum for Team System), at the same time as another is just starting...
It is true that to garner all of the benefits of TFS, it is best to use separate projects, but those benefits should be weighed against the administrative overhead associated with managing many projects. Years ago, I used Visual Source Safe...After I left Microsoft, I switched to Subversion. After returning to Microsoft, I am using TFS and so far I am very happy with it.
The process guidance, the reports, the integrated bugtracking, and the tight IDE integration serve my needs perfectly. Plus, the TFS SDK allows for some interesting extensibiilty scenarios.
I've used several SCC providers and we've settled on TFS for all of the features it has that others don't. Bug correlation, CI and automated testing certainly topped the list of benefits.
As for whether you use multiple project or not, I'd say it depends on if the projects share any common code. We tend to use a TFS project for all "related" code assets, so if we have several different solutions that do similar things and share a lot of code, we use a single TFS project. If they have nothing in common, then they become separate projects.
I am not sure if this was fixed in 2008 but in 2005 when you built a project that was a subfolder of a root project, MSBuild will pull the entire source tree of the root project - even files that are not part of your subfolder.
Depending on how much source you are managing this can greatly increase your build times.
I realize this article is old, but TFS 2010 now supports a wonderful feature call Team Project Collections which is simply another level of indirection or grouping on top of Projects.
This makes it much easier to create Team Projects without clogging up your namespace and encourages better organization!
Great Link talking more about Collections
http://blogs.msdn.com/b/bharry/archive/2009/04/19/team-foundation-server-2010-key-concepts.aspx
I a not a sharepoint user but I hear its very similar concept to Sharepoint collections :)
Around here we have been working with a bunch of Visual Source Safe repositories for about 10 years or so.
Now I want to get rid of sourcesafe and move on to Team Foundation Server.
Do you have any tips or tricks for me before I embark on this migration? What are the things I have to be careful about?
I am sure this migration will mean that our working habits have to be modified in some way. Do you think that these changes could be a problem for the organization? Think about a group of about 20 .NET developers in a single site.
There are a few different ways you can migrate. The tool will pull your history, etc. over, but the more pragmatic and simple way is to lock VSS as a history archive and start fresh:
Have everyone check in all changes into VSS, make sure everything builds, etc.
Set all VSS databases to "locked" (read-only rights for all users)
Get Latest on the entire VSS database into a "clean" set of folders on a workstation
Check all of the files into TFS from the workstation
For any history prior to the conversion, folks need to go to VSS, but after a week or two it's realistically unlikely to happen all that often. And you know that the history in VSS is accurate and not corrupted by the conversion process.
Be aware that TFS does not support sharing files between different projects, as VSS does. If you have any such shared files the link between them will be broken during the migration, resulting in initially identical, but now distinct files in each project. Updates to one of these files in TFS will no longer propagate to the copies in the other projects.
If you do choose to use the VSSConverter.exe tool that ships with Visual Studio Team Foundation Server, then you should install TFS 2008 SP1 first as it includes a number of improvements as detailed on this blog by the migration tools team.
Some of the key features of the
release include:
Elimination of namespace conflicts. I
previously blogged about this as "the
rename problem" and we have fixed the
converter to correctly migrate files
with overlapping namespaces. This was
the biggest pain point for most users
trying to use previous versions of the
tool.
Automatic solution rebinding.
In this latest version, VS solution
files will be automatically upgraded
to the 9.0 version and checked back in
to version control. Previously users
were required to do this manually.
Correcting of timestamp
inconsistencies. The use of client
timestamps by VSS can lead to
revisions being recorded in the
opposite order that they actually
occurred in. The tool now recognizes
this issue and continues migrating
changes where it would previously
fail.
Improved logging. Although
we've fixed a lot of issues, providing
better, more detailed logging will
help users that do run into issues
diagnose the problems.
I just googled, but this walkthrough seems like a good reference, and it mentions the tool VSSConverter which should help you make the migration as painless as possible.
I would like to recommend one thing though: Backup. Backup everything before you do this. Should anything go wrong it's better to be safe than sorry.
My links aren't showing up. This is the address: http://msdn.microsoft.com/en-us/library/ms181247(VS.80).aspx
We are currently in the process of doing this at my day job. We are actually making the switch over in about a month. I am a main part of the migration and a big part of why we are getting off of SourceSafe. To help in the migration, I used the Visual Studio® Team System 2008 Team Foundation Server and Team Suite VPC Image. It was very useful. Right off the bat, the image contains a full working TFS installation for you to play and demo with. It also includes Hands on Labs and one of the labs is running the VSS -> TFS migration tool. If you have an MSDN subscription, once you have played with the image, the next step would be to install the TFS Small Team edition that comes with your subscription.
One thing to note is to make sure you get the latest Service Packs for Visual Studio 2008 and the .NET Framework installed on the image. The service packs fixed some annoying bugs and it definately increased the usability of the system. We have a farely large SourceSafe database with about 90+ projects and the migration tool took about 32 hours to complete. First I made a backup of our sourcesafe database for testing. Then I made the migration on the test sourcesafe database. Afterwards, I checked the source tree in TFS and everything transferred fine. We kept all the history for our source files from VSS which was great. No need to keep that stinking VSS database around after we go live.
We are taking the migration in steps. First the source control and letting our developers get use to using it. Then after that we will be migrating the QA and Business Analysts over to use the Work Item tracking features.
My advice is to take the migration in steps. Don't do too much at one time. Give time for people who will be using the system to train up.
VSS Converter is a far from perfect solution. And there are significant differences between the 2005 and the 2008SP1 version of the converter.
For example, in a VSS DB that's been in use for a long time, there will have been a large number of users contributing to VSS. Many of these users will have left the organisation a long time ago and therefore will no longer have domain accounts. TFS requires mapping VSS users to domain accounts, so you will have to decide whether you map old users to a single 'dummy' domain account or to a current team member.
In addition, VSS Converter 2008 requires these domain accounts to be valid TFS accounts. Whereas the 2005 converter does not enforce this.
If your VSS history contains significant folder Moves, then it's likely you will loose all history before this Move. For example, if you Move a folder to a new location, then Delete the previous parent, you will loose all history. See this article for more explanation:
http://msdn.microsoft.com/en-us/library/ms253166.aspx
In one migration I was involved with, we had a 10 year old VSS database that lost all history prior to 6 months ago. This was due to a significant tidy up that took place 6 months ago.
TFS conversion tool <-- Use this
I've used this tool for some times already, the results are pretty satisfatory as it comes with the history of changesets from SourceSafe if you desire too.
Anyway, using this tool you should always pay attention to errors and warnings in the log, and check if everything built okay / passed okay.
It's recomended to also run an Analysis on SS before running this.
Hope it helps
Good guidance there from my former colleage Guy Starbuck. Another thing to add with that approach - you may have decided over time that you want to refactor the way your application is organized (folders etc) and this will give you an oppurtunity to do so.
I've been in situations where we organized a solution haphazardly without thought (let alone major changes in the application) which led to a desire to organize things differently - and the move from VSS to TFS is a great oppurtunity to do so.
As far as the original question:
And: this migration will for sure mean that our working habits have to be modified in some way. Do you think that this changes could be a problem for the organization? Think to a group of about 20 .net developers, in a single site
I would say - yes your working habits will change but much more for the better.
You no should use "Check-out" Locks and "Get-Latest on Check-out".
You can now effectively Branch and Merge
You will now have "Changesets" all files checked-in at the same time will be grouped together. This makes historical change tracking much easier - but more importantly - rollbacks are much easier (ie find all files checked in at the same time and roll them back)
Associating Check-ins to Work Items. Don't overlook Work Items! The biggest mistake you can make is to only use TFS as a VSS replacement. The Build and Project Management features are excellent - you paid for them - USE THEM!
As far as details on how your experience will change, another former colleague of mine (and Team System MVP) Steve St. Jean wrote a detailed article on the differences: From VSS to TFS