7 Replies - 207 Views - Last Post: 03 May 2019 - 12:08 PM

#1 maceysoftware   User is offline

  • Member Title
  • member icon

Reputation: 370
  • View blog
  • Posts: 1,600
  • Joined: 07-September 13

Source Control and TFS

Posted 03 May 2019 - 03:49 AM

Hello,

We are currently looking to replacing our SourceSafe (yes I know, long time coming).

We have chosen to go with Azure Dev Ops, along with having the Azure Dev Ops backend rather than git, there are a few reasons for this but things like (Linking work items to check-ins, check-in policies are but a few), we have also read that if we wanted to switch to git afterwards it is fairly straight forward.

We are also aware that you may have more control of work items and check-in policies in future releases, but when integrated into VS 2015 we can't see any reference to either but we will be re-assessing our choice when we upgrade Visual Studio, but that won't be for a few years I predict.

My question is how do people handle releases whereby when you need access to the release code to create service packs?

With SourceSafe we wrote our own MoveOver Application, which basically got latest from our development environment and created a new SourceSafe Database, adding the files to build up a release SourceSafe, it would also recreate the users from Development into this new database.

We did this to allow our developers to connect to that particular version to make changes for a particular version's next service packs.

From what I have seen from Azure Dev Ops, it won't be that simple, but I can see multiple ways of doing this:

The first is we detach the Development Collection, Backup the database, Restore the database and copy the collection so we now have Development Collection and Version 1.0.0 Collection, downside is having multiple collections if we do a release twice a year and keep the last 5 years versions, that's 11 collections including Development always being up.

The second option and the option I prefer would be to have a Development Collection and a Release Collection, When we are ready to do move Development over to release, we could create the new release project, get latest of the development project and add it to the release project. However, this is more involved than I like, currently, it takes a good 30 minutes just to get the latest in SourceSafe, I know this should be faster in Azure Dev Ops, but the tool we created for SourceSafe allowed us to walk away or for me to run it out of hours without having the babysit the process. This application tended to always be run out of hours because if someone checked in while it was getting latest it would fail.

I can't be the only one thinking this is too manual, so because of that is anyone aware of any tools you can use to copy a project from one collection to another.

So far I have found out, everyone would love this feature to move projects between collections and it has been on the UserView for a TFS for over 8 years, I personally think, still hoping that they will introduce this feature now is a fools dream, with them now backing their GIT back end over there TFS backend I don't see this happening, mainly because I can't see us handling releases in the same way with GIT anyhow, but I might be mistaken.

I have found the following tools which I will be investigating today if I get a chance:

https://marketplace....igrationUtility
https://dev.azure.co...migration-tools

Is there another way that we should be investigating?

Regards

Is This A Good Question/Topic? 0
  • +

Replies To: Source Control and TFS

#2 modi123_1   User is offline

  • Suitor #2
  • member icon



Reputation: 14992
  • View blog
  • Posts: 59,853
  • Joined: 12-June 08

Re: Source Control and TFS

Posted 03 May 2019 - 06:54 AM

Oh heck, I didn't realize AzureDevOps is just renamed Team Foundation Server!
Was This Post Helpful? 0
  • +
  • -

#3 maceysoftware   User is offline

  • Member Title
  • member icon

Reputation: 370
  • View blog
  • Posts: 1,600
  • Joined: 07-September 13

Re: Source Control and TFS

Posted 03 May 2019 - 07:01 AM

Sorry, I should of put that.

It's as of their 2019 release.
Was This Post Helpful? 0
  • +
  • -

#4 modi123_1   User is offline

  • Suitor #2
  • member icon



Reputation: 14992
  • View blog
  • Posts: 59,853
  • Joined: 12-June 08

Re: Source Control and TFS

Posted 03 May 2019 - 07:05 AM

We use TFS.. don't really automate build do to our chain of approval and release methods.. but yeah, there are automated tools and I do remember seeing MSDN articles on it... lost them currently.

Depending on the project, and the sub team, we have branching and what not.. so Main trunk for an app then devs get branches, make changes, merge, and deploy.. a bit of a PITA if there are a sizable number of people but do able.
Was This Post Helpful? 1
  • +
  • -

#5 maceysoftware   User is offline

  • Member Title
  • member icon

Reputation: 370
  • View blog
  • Posts: 1,600
  • Joined: 07-September 13

Re: Source Control and TFS

Posted 03 May 2019 - 07:51 AM

It's not really our builds that I am talking about here, I mean we need to investigate that as well but for the time being, is just how to handle our release code.

For SourceSafe we have a development code repository which all our dev changes go into, however, whenever we release a version of our software we branch the repository off into a new SourceSafe Database.

This allows us to go back to certain release version to do bug fixes, sometimes this might even mean back-fitting a development ticket. so, for example, we could have

Development
Release_Version1
Release_Version2
Release_Version3
Release_Version4

I am aware we could Branch for every release but it seems a bit clumsy when you're doing several releases a year, which is why we like the idea of copying the development project across to a release collection, so it's completely standalone and clear if you're connected to a project on the release collection then its obvious your doing backfits.

Hoping that make's sense, maybe branching is the way to go, will give it another look, just concerned it could cause confusion for people who have been using SourceSafe for so long.
Was This Post Helpful? 0
  • +
  • -

#6 Skydiver   User is offline

  • Code herder
  • member icon

Reputation: 6877
  • View blog
  • Posts: 23,324
  • Joined: 05-May 12

Re: Source Control and TFS

Posted 03 May 2019 - 11:06 AM

With TFS, there is no need for a separate database. You simply create branches within the same database. Each branch keeps track of the version of the file that should be there.

If you people are getting confused by the branching nature, you should create batch files for your team which are the "blessed" ways of checking out a particular "release" and checking in fixes against it.
Was This Post Helpful? 1
  • +
  • -

#7 astonecipher   User is offline

  • Senior Systems Engineer
  • member icon

Reputation: 2836
  • View blog
  • Posts: 11,125
  • Joined: 03-December 12

Re: Source Control and TFS

Posted 03 May 2019 - 11:52 AM

View Postmaceysoftware, on 03 May 2019 - 09:51 AM, said:

just concerned it could cause confusion for people who have been using SourceSafe for so long.


Oh, it will cause confusion regardless, unless you stick with sourcesafe, there is a learning curve with anything you pick.

However, [Azure]DevOps allows you to do Release pipelines, CI definitions, Deployment Groups, and several other things, as well as have an integrated environment for creating branches for development. It is a learning curve as I said, but you will get that regardless of what you do, but the options you have with VSTS are pretty large for future development. Hell, my company decided to upgrade us to VS2019 in order to leverage some of those options!
Was This Post Helpful? 1
  • +
  • -

#8 maceysoftware   User is offline

  • Member Title
  • member icon

Reputation: 370
  • View blog
  • Posts: 1,600
  • Joined: 07-September 13

Re: Source Control and TFS

Posted 03 May 2019 - 12:08 PM

Thanks guys for the information, there is three of us doing our migration to DevOps so its nice to get an outside prospective, I can go into the meeting next week knowing that branching is what other company's do if nothing else. It has been interesting learning all about the different options if nothing else.
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1