I have recently got an opportunity to migrate 26K lines of code spread across multiple repos serving consumer facing application ,serving millions of customers , through mobile applications.This is flask application running on gevent with lot of background tasks, in AWS ECS. I felt this experience will be of much use to the community. I tried to pen some of learnings down here.

Testing

First and foremost thing needed for migration is - presence of unit tests. if unit tests are not there at all, please write them first. If you have unit tests and you feel they are inadequate , first invest time in writing those unit test cases. With out tests, do not make an attempt to migrate.

Wisdom

• Create .tox file and run all your tests with Py2 and Py3. It saves lot fo time
• Create locust tests (load test) to test end to end flow in uat .

Branching

In practical world, feature additions will be given preference over migration. So when you create a branch for migration and that will last longer than you image. Brace yourself for lot of merge conflicts.

Commits

Create as many commits as you logically solve a problem. As soon as you have fixed some logical problem, commit it and create as many commits as they will be great help in future when you want to reference. You will end up referencing them when you have multiple repos to migrate.

Conflicts

If the project is long running, please try to rebase with your develop/staging for couple of weeks.If you have not rebased in long time, you will be for lot of surprises.

Wisdom

• This command git config --global rerere.enabled true will be of great help as it remembers the all resolutions you did and replays in subsequent conflicts. It saves lot of time.
• Sometimes you forget to resolve few(non python files, hidden(circleci config)), this results in huge mess later . To avoid that this command will be of great help ag ">>>>>" --hidden --ignore-dir .git always execute it before you do git add .;git rebase --continue

Code review

Please work it within team if it is worth reviewing the code all at one go or at commit levels.Having as many commits is certainly going to help the reviewer. As long as unit tests are passing, that is good indicator of working code. You can decide among your team what is the right strategy here. As changes are difficult to review. If you delete some code or test cases or libraries, keep your team in loop.