Developers often inherit legacy codebases, and sometimes those codebases do not have version control. How do we maage that?
I recently joined a team, and while they tried to have some good practices in place, it really was a mess. Luckily they know that, so I am not saying something they don’t already know. 😉
They had 4 production servers and 1 development server. So when I started, I thought that was a great setup. They had SVN in place, and while I am a Git guy, I figured I could pick up SVN just fine. After starting, I learned that they didn’t use SVN very well, and that much of the code was not in sync.
I wanted to get rid of SVN and introduce git into the mix. My boss was very open to the idea, and surprisingly, so was the rest of the team. There was a HUGE issue though. So many changes have been made in production, so there could actually be 5 different versions of the same file across all of the machines. And not just different versions, but completely different functionality within said file.
Because of these facts, my boss was hesitant about my desire to use git. I convinced him that I would take it slow, and I laid the plan out in front of him. Because of my slow and methodical approach, he gave me the approval to move forward. You don’t have to add all of your code into a version control system all at once. Start slowly with a well laid out plan. And I don’t mean that you have to know every file in your codebase and the order you want to add them. My plan was to start with the files we were currently working on.
Our steps when we needed to change a file:
- Copy all 5 versions to the dev server. Creating different file names of course, these will just be temporary files.
- Use some process to figure out the differences between the files.
- vimdiff is a great tool for this. It can help you merge up to 4 files at once.
- The goal is to get a single files that could be in 5 different states into a uniform version that should work properly on all 5 systems.
- Remove the temporary files
- Add the newly merged version into git
- The key now is to keep a backup of the various version “Just in case” and get the newly merged code into production.
- Lather, Rinse, Repeat
The process is still not complete for us. However, we are in a MUCH MUCH MUCH better position then we were a few months ago. I can make changes and test in development, and deploy most of our code fairly easily.
The fact that a company that just hired me, had that much trust in me to completely change their workflow, was pretty impressive as well.