1. Decision to adopt an SCM system
2. Adopting Team Foundation Version Control
3. Switching to Git
4. Conclusions

No Source Code Management?

It isn’t fair to say that we didn’t have any source code management in the old days. We did. The system was composed of certain expectations about how development was done and some manual checks that they were followed.

• Development was done in the test/dev database before being moved to live
• You could trust the Modified flag – any objects that had been changed from standard would be ticked as Modified
• The date and time on the object would represent the last time the object was changed (therefore you could compare object datetimes between databases to judge which objects were different)
  • Developers would often check that the datetime in live was the same as test before starting development in test
• Dated and initialled comments were added to the documentation trigger and modified lines in the code

In addition to these assumptions, generally

• The original developer would also put their changes live – they knew which object(s) to move
• The developer would take a backup of the objects from the live database before importing from test
• We were a small enough development team that we could talk to each other about changes that had been made
• The same developer would work on the same customers
• Support would refer cases back to developers, especially if issues arose after some objects had been moved into live

All of this is, in itself, a system. Sure, there are problems with these assumptions, the steps weren’t always followed and it doesn’t scale too well but this is a source code management system. Of sorts.

Adopting a SCM System

So why did we choose to adopt a new SCM system? The main reasons were these:

• We’d had instances of SQL databases being deleted which contained the only copy of some work. Lots of hours’ worth of work
• We often had occasions where it was difficult to piece together what changes had been made and why – particularly if the documentation in the objects was light/absent
  • This was particularly problematic for support developers landed with a case that starts “we’ve had some changes go live recently and now xyz isn’t working”
  • While we’d try to go back to the original developer (see above) if this wasn’t possible the support developer would have the difficult task and trying to work out what had actually changed
• We didn’t have a reliable, single place to go for previous versions of objects – either to refer or rollback to
  • Developers would take ad-hoc backups of objects before moving them live
  • We’d have a support copy database of most customer’s objects on an internal SQL server
  • We experimented with a homemade backup system that pulled copies of objects from support databases – but not from databases hosted on-premise where development was often done
• The team was growing – both in terms of staff and number of projects – to the point where it wasn’t practical to rely on the same developer always working on a particular project or on ad-hoc communication between developers, support and consultants to manage the objects

It became clear that we needed a central system to manage our development in. We’d need to:

• Backup copies of our objects
• Track changes that had been made, when, by whom
• Rollback objects to previous versions

Fortunately this realisation coincided with Luc van Vugt running a workshop at NAVTechdays about source code management with TFVC…