Code migration can be tricky if you’re not prepared. Follow these steps for a worry-free migration.
Almost all source code contains some format of delicate information, whether it be configuration-related information such as database credentials or information on how the web application functions, such as a web template.
If such information is disclosed, this information potentially could be used by an attacker to discover logical flaws and escalate into a successive chain of attacks. These include attacks such as SQL injection, database takeovers, cross-site scripting, remote code execution and, sometimes distributed denial of service.
To achieve solution for conducting a risk-free and systemic migration, we need to plan three stages for the code migration process: pre-migration, migration and post-migration.
Key Considerations During Pre-Migration
- License cost
- Administration cost
- Developer productivity
- Security of data
- Training of team
- Total cost of ownership
- Knowledge on all connected tools with application lifecycle management
- Agile adoption policies and CI practices
- Team structure – distributed or co-located?
- File types – Do you have large binary files?
- Need file locks?
- Users have the appropriate permissions to fetch and push
- Builds are successful, and all your tests are passing
Key Considerations or Challenges During Migration
- Test environment
- Capacity planning
- Compute capacity
- Benchmark the current version control system
- Network connectivity
- Access between source and target servers
- Load testing
- Access control
- Aim to migrate over a weekend when nobody needs to check-in
Key Considerations During Post-Migration
- Data integrity verification
- Data size check
- Automated acceptance testing and reporting
- Dependencies are intact and build doesn’t break
- Link between files and folders is not broken
- Load testing
- Backup and sync jobs
Moving to Distributed Version Control from Centralized Version Control
When migrating code from a centralized version control system such as Apache Subversion (SVN) to a distributed version control such as GIT, here are the steps to take:
- Evaluate the tools and methods you’re planning to utilize
- Build and test
- Code reviews
- Release management
- Select a branching strategy for GIT
- long-lived feature branch
- Short-lived feature branch
- Bug fix branch
- Dev branch
Reference: https://guides.github.com/introduction/flow/index.html
https://nvie.com/posts/a-successful-git-branching-model/
- Decide whether you want to migrate history; if yes, then determine how you will achieve this—you may need another third-party tool to resolve your task.
- There are many tools available in market that can migrate a whole history of all branches from a centralized tool to GIT.
- Almost all version control systems collect how files change between versions, including rename, merge and rollback. GIT version control tool stores versions as a snapshot of the entire repository.
- Retain your old version control system for a set time after migration.
- During and after a migration, developers sometimes need access to the history in the old version control system, so you can’t just shut the old system down once you’ve migrated.
- There should be some text file committed in GIT which should explain how/when the GIT branches were migrated from the old system and what all branches are migrated.
- Remove binaries and executables from source control.
- You should avoid commit large binary files to a repository. Once they’ve been committed to a repository, they will remain in the repository history and in every upcoming clone.
- Migrating to Git provides you the opportunity to remove these binaries from your codebase and instead use a package management system.
- Give knowledge transfer to your team in the concepts and practice used in GIT.
- It is mandatory for developers to understand how Git stores change and how commits form a history of development and how all things work in GIT.
- Identify training materials.
- Perform the actual migration to GIT.
Suggestions:
- Keep the following types of files: code files, versioned assets such as graphics and large configuration files.
- Remove the following types of files: database dumps, log files.
- Use a vulnerability checking tool.
Conclusion
By following the above key steps, you can have a systemic and risk-free migration. Planning, then acting, is critical in a successful code migration process.