I would like to create a new installation of TFS 2013 on a new server.
I made my research and learnt that the migration process as it is described on this link below carries some risks:
TFS Migration Manual:
https://msdn.microsoft.com/en-us/library/ms404869.aspx
Risks:
http://blogs.msmvps.com/p3net/2014/04/12/tfs-upgrade-nightmares/
I have a plan to avoid using the TFS Migration manual above, instead; I would instead check all of my projects out (about 20) and then re-create them on the new TFS and check them in again.
However, we have work-items, users, workspaces and other agile information which I have created for my projects, and which I still require to be on the new installation.
I was wondering whether the following works (again without risks and hassle, as time is scarce):
Back up the TFS Databases from the old installation, and restore them into the new installation or simply import the data from old to new using SQL Server's Data Import Tool.
I am particularly referring to these databases, which TFS has:
Tfs_Configuration; Tfs_DefaultCollection; Tfs_Warehouse.
I found these databases on the SQL Server instance which TFS uses.
Also, this approach works easier without having to obstruct the team, as the Data Base Resotation can occur after hours..
Now, will this plan work?
No, your plan will not work and will leave your TFS in an unsupported state.
You need to follow a combination of the Upgrade and "changing environment" workflow.
1) Restore all TFS databases (tfs_*) to tye new environment
2) Install TFS 2015
3) Configure and select Upgrade Wizard - when running make sure you have all the new server names
4) (optional) ChangeServerID - if this is a practice run you should then immediately:
4.1) I unconfigure the application tier with "tfsconfig exe setup /uninstall:all"
4.2) run the ChangeServerID command
4.3) reconfigure tfs and run the "app tier only" wizard
Simples....
Note: You need to change the server ID if this is a test/practice instance as each server gets a unique ID. When clients first connect to the new server they will "upgrade/migrate" the users data across. You don't want that happening for a trial...so change the ID...
WARNING: If you manipulate the data in the TFS server in any way that is not done by the TFS Product Team tools you will turn your instance to crap. Do not ever edit, or cause to edit, the data in the operational store.
Related
I am having an issue with the dbo.__MigrationHistory table not being updated with new database migrations, BUT the actual database itself is correctly updated with relevant changes. This means the site won't load due to it spotting a change in the context - and I have to manually insert the new changes into the dbo.__MigrationHistory table to make it load.
When I publish to Azure from Visual Studio everything works fine in my PRODUCTION site. However, I have the issue only on my TEST site (which has a different publish profile).
I have checked the EXECUTE CODE FIRST MIGRATIONS box in the publish profile on both the TEST and PRODUCTION publish profiles. Indeed, both publish profiles appear to be identical except for pushing to a different site.
In case it helps - whenever this happens my localdb SqlServer database also becomes unattached during the publish. So on my local PC I have to then go back and reattach the .mdf database file in SQL server management studio.
Any help / advice you can offer would be amazing.
I've had a number of occasions where Entity Framework migrations have left the state of migrations in an unusable state. Usually this happens after a large number of migrations have been applied from different developers and get stuck to where we can't update a database with new migrations or roll back.
It's simply easier to delete the migrations and start with a clean state from the current schema.
If you go the Route of resetting your migrations, make sure you back up your code and make known good backups of your database.
In summary, the steps to do this are:
Remove the _MigrationHistory table from the Database
Remove the individual migration files in your project's Migrations folder
Enable-Migrations in Package Manager Console
Add-migration Initial in Package Manager Console
Comment out the code inside of the Up method in the Initial Migration
Update-database in Package Manager Console(does nothing but creates Migration Entry)
Remove comments in the Initial method
This is not a ideal work around but this will resolve the your issue.
P.S.- This usually occurs when somebody update DB from local machine and it goes out of sync.
I have an on-prem TFS, In that there are too many change-sets are available. Now I'm using Visual Studio Team Services (VSTS) for same project, but I want to integrate my on-prem TFS change-sets also at VSTS. It means, If in my on-prem in have change-set from id 1 to 987, after integrate I want whenever any developer check-in any code in VSTS it start from 988, not from 1.
There is no documented way I am aware of. You have a tiny tiny thin chance going through Microsoft Support by opening a Service Request (i.e. a support ticket) and hope to touch their heart enough.
If I were you, I would redesign my tools/process to work around this issue e.g. if you use the changeset number in communication prefix with a letter the numbers from the new system.
The 'dirty' solution is to make and commit ~987 non-important changes (add/remove a line etc.) using a script. Afterwards you can destroy those changesets, but you changeset counter is now at the right number.
This absolutely not a pretty solution but I think that you would have more success with it than through the support.
My team currently works with an on-premises TFS 2012 server. I am migrating everything to Visual Studio Team Services, formerly Visual Studio Online. I am starting with a test project and was able to easily get all the code migrated, but can't figure out how to do the same for the work items.
Are there any good guides out there?
New options as of March 29th 2018:
TFS to VSTS migration - The official import option which will import 1 project collection into 1 VSTS account. It automatically imports everything stored in the backup. At the point of writing this, the TFS must be upgraded to TFS 2018 and some work item template customizations must be removed (there are a few well documented features unavailable on VSTS).
VSTS Sync Migrator - Marting Hinshelwood, the uncrowned king of TFS and VSTS migrations, has built his own little tool that can migrate work items from one server/account to another. It can even do migrations from one Team Project to another and while doing it switch between process templates.
VSTS Work Item Migrator - Microsoft has also open sourced a project that they used internally to migrate work items. It's less powerful, but it was made by Microsoft.
Previous answer:
At the moment there isn't a really good story. Your options are:
Start over - easiest :).
Start over and manually recreate items of value - It's a pain, but it's some teams have done these things in the past. keep the old TFS server available in read-only mode and each time you use a work item in the old system, you manually create it in the new one, set all the fields and upload the attachments. Depending on the number of items it'll take you a few sprints to migrate the most important stuff over.
Wait a while longer - Microsoft is currently working on a full fidelity import option which will allow you to upload a Project Collection and it will be exposed as a new VSTS Account (it's not going to be possible to import a project collection into an existing account).
Use Excel for import/export - Will work for most work items, you loose attachments and work item links other than parent/child. The trick is to extract from one Project Collection then copy all fields, except the ID to an Excel sheet bound to the target project collection. You will need to fix all Identity fields (works best when users have the exact same display name on premise as in VSTS) and you'll have to import once with state new and then past the current state/reason over the just imported values and sync again. Test Cases, Plans, Suites and Shared Steps will not be imported with their relations in tact. The approach would be very similar to this one.
Use the TFS Integration Tools - Will work for most work item types, though it will loose custom kanban states and tags. Test cases, Shared steps and their relations will not be imported. This option will allow you to import import work items and source code with their relationships in tact.
Use a 3rd party solution - Out of the available options currently OpsHub offers the most complete solution. For test case and source control link migration you're looking at the commercial edition, which comes at a steep price. It still has a long list of known issues and last time I tried it, I ran into numerous issues which required their support to resolve them.
There are specialized TFS consultants who live off these kinds of migrations if your current state of the work items is precious to you, then you could reach out to them.
See also:
https://www.visualstudio.com/en-us/articles/adopting-vsts
I use WebMatrix for deployment of files and databases during development. I want to continue to use it after development for updating files on the host. I also want to synchronize my local database to the host database, but never the other way around. I am terrified of accidentally overwriting the database on the host.
How can I do what I want while safeguarding against accidental updates of the database on the host? Essentially, I am looking for a way to tell WebMatrix that the host database is read only and not to be updated.
You can link the development project to the live database. That way you can still develop the files offline while using the actual data to do it. If you link to the database WebMatrix won't attempt to update it as it will already be working with it. Yes, if you make a change for development purposes it will change it on the live site. However, if you are only developing the webpages this should not be a concern. To link to your database just go to the database workspace and click on the New Connection icon. Just remember any changes to the database in WebMatrix after that point will be immediately sent to your database.
We're starting new web site development with Umbraco, and having some difficulties with optimal setup for multiple developers.
Right now we have a complete umbraco install in a code directory, with IIS pointing to it as well, and a local DB for each developer. We're planning to use Courier package to push/pull content changes, and Git for source code.
This setup allows to debug from Visual Studio (using F5), instead of attaching to a w3p, which is annoying. Separate db is a part I don't really like, I'd prefer a shared one, but with Umbraco's caching model (in xml file) this isn't optimal either - changes to data types etc are not reflected in other developer's environments. This does mean, however, that sharing changes among developers is a 2-stage process - Git + Courier.
I'd guess people have already came up with some best practices on umbraco setup for team development - would be nice to hear about them.
Thanks !
We use a central source control system for the code and share one database with all developers. This works quite good, but after a change or update of the source control repository, the only thing to keep in mind is that you need to update the cache (right click the root content-node in Umbraco and "republish entire website").
With this setup we all share the code and database in the development stage. Courier can then be used to transfer umbraco content back and forward to the test and production environment.