My organization formerly used TFS, but has now upgraded to the latest version of ADOS 2020. There are several things that collections that were created after switching to Azure DevOps Server 2020 can do that still involve a process on our collections brought over from TFS, such as updating WITs. What is the process for making these collections ADOS ones? Do we have to just recreate them and data dump from one to another? If this is the case, how do we transfer all of the historical data on our work items and CI/CD pipelines?
We have experience using the query tool to import new projects into ADOS, but want to know if there is an easier process since it is TFS to ADOS and we want to save our data.
Related
We are planning to migrate over from TFS 2015 to Azure DevOps, and the task assigned to me is to find out the way to do a comparison after the migration between what we have on TFS and Azure to ensure that all the tasks, bugs, etc was successfully migrated over. I've checked with the Guide from Azure and found nothing about such post migration checking and comparison. Is there any tool for this or we can only do the whole checking and comparison manually?
There is no such tool.
I have never experienced a partial migration. Due to the way the import works that is also VERY unlikely. Either the complete import fails, or the data is going to be there. I've done many of these migrations as well as server migrations/upgrades and the kind of data-loss you're worried about has never happened.
The one thing you'd need to be careful of are the changes to the retention policies.
How to transfer the repository or a whole set of repositories from one gitlab group to another subgroup. For example companyname.gitlab.com/team one/. To gitlab.com/team_first/phase1/
The repositories/projects themselves still need to be exported by API, one by one.
But the new "Group Import/Export " feature from GitLab 13.0 (May 2020) can be a welcome addition.
Export and Import Groups in the UI
Previously, users could only migrate groups by using the Export/Import API to create an Export file, then using the API a second time to upload the file to the target instance.
As a first step toward a more frictionless solution, we have enabled Group Export in the GitLab UI.
We plan to introduce similar Import functionality to the UI within the next few weeks.
See documentation, issue and Epic.
See GitLab 14.2 (August 2021)
Group Migration achieves parity with group import/export
The new GitLab Migration feature can now migrate an entire group with all its subgroups and related data. The data migrated includes everything contained in group exports, making this a much easier way to migrate entire groups.
The pre-existing group import/export is a two-step process that requires exporting a file and then importing it into another GitLab instance.
Now, users can initiate a group migration with a single click. Migration also includes all the subgroups and their data, which previously required separate export and import processes for each subgroup.
See Documentation and Epic.
See GitLab 15.6 (November 2022)
Associate MRs to issues when migrating groups with projects
When migrating groups using GitLab Migration, GitLab now preserves associations of imported merge requests to issues.
This populates the Related merge requests section
on the issue details page.
See Documentation and Issue.
We are starting to use TFS2013 (we use svn still, but for a number of reasons we're putting new code on TFS).
I have a solution that contains a project with an EF database model and I would like to share it with a different solution (to be more specific: there is a client website solution and a separate one for backend).
On SVN I would have created svn externals - I would be able to share the code easily and if I branched, the shared project would have a nice copy on branch as well. Moreover, both projects would have the most up-to-date version of the db model, which suits me perfectly.
TFS 2013 seems to push be pushing towards NuGets. That means, that if I create a nuget package of the db project:
I will have to update the db projec separately each time there is a db change, release it and then update all projects that use it
If I branch, I'll probably have to create a different nuget package for the branched version and amend the nuget reference on merge
It pollutes the nuget repo with things that are not exactly worth a repository (in case of a DB model, you want to have the latest possible version because a website will probably break if you don't, no point for versioning so that the build doesn't break)
I spent some time trying to find a suitable solution, but the best idea I found is just referencing the project from a different solution - the problem with it is, I would have to make the root folder for the build be higher than just the solution and that would add several more projects that I don't need. Another idea is referencing by branching, which was good for TFS 2010 with multiple projects, but I can't fit it into my scenario (we have a single 'Main' node where we put all solutions).
So, how would you share a DB project on TFS 2013?
I want to copy an entire TFS project to another project, e.g. MyProj to MyProjSev. Then I want to rollback MyProjSev to a changeset that corresponds to when the client stopped paying. Then I will make MyProjSev available, including the history of the source files, to the client for a period of time as part of the severance agreement. The access/security aspect I know. I can easily make a branch, but if the client views the branch from a TFS Explorer Client, then the history is not available. There are a couple of approaches that involve cloning the entire collection, and lacking an answer to this question here, I will use one of them.
https://stackoverflow.com/a/4918289/553593 [TFS admin detach the collection, back up SQL Server database, TFS admin attach collection, SQL Server restore database to new database name, then TFS admin attach the restored collection]
http://msdn.microsoft.com/en-us/library/ee349263(v=vs.100).aspx [Collection command with /clone]
New Information http://visualstudiogallery.msdn.microsoft.com/eb77e739-c98c-4e36-9ead-fa115b27fefe TFS Integration Tools was what finally worked for me. This 2012 release is a very nice product. It was easy to do a TFS to TFS transfer from my MyProj to the new MyProjSev that I created for client to access. Upon completion I simply did some rollbacks and set the security in the new project. It would have been easier if in TFS 2010 one can rename projects (can do in TFS 2012) Neither the TFSConfig Collection /clone nor the procedure described in MS Docs for Splitting a Team Projects Collection will work for this task. The issue is that even though one ends up with two collections, their projects have the same names, and that is not allowed (and in TFS 2010 you cannot rename projects).
The best option is to clone the collection as you suggested.
I answer my own question as described in New Information above in the text of the question. Note all this is specific to TFS 2010.
I am using SVN (Subversion) which is a file versioning software, and stores the changes on code artifacts in the form of revisions.
I want to use the similar kind of software for DB2 objects like Tables and indexes, so that I can track changes over them using revisions.
Have anyone done this before?
You can use the IBM Data Studio client that creates a deployement group for database changes.
Once you create a deployement group, you can save it, and apply to several databases.
Take a look at
http://pic.dhe.ibm.com/infocenter/dstudio/v3r2/topic/com.ibm.datatools.deployment.manager.ui.doc/topics/c_deploy_mgr.html