Skip to content

paul-hammant/arbitary_merge_testing

 
 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

15 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Arbitary Merge Testing

Testing arbitrary merges across branches to prove a version control system can handle years of changes across branches! This is an extension of Paul Hammant's subversion testing

Why?

This is part of a system to prove suitability of a version control system as backing store for a configuraton as code implementation.

Systems

This is purely to validate perforce. Subversion has been ruled out due to merge limitations. Git has been ruled out due to lack of fine grained authz controls.

Running

  • Install dependents
    • moreutils - this provides sponge
  • Checkout https://github.com/paul-hammant/fast_perforce_setup alongside the current repo.
  • Unless you already have them, download all the p4 binaries and add them to path. Helper script: fast_perforce_setup/get_binaries.sh
  • (If running for long iterations, you might want to run this nohup, and redirect output to a log file!) Run run-the-tests.sh

Documentation: Branch setup

  • Branch: DevBase - All changes/config items start here
  • Branch: UatBase - All changes move from DevBase out here, where they are propagates to all client UAT environments
  • Branch: Testing/Ajay/Uat - Config for personal UAT environments for testing / staging / etc.
  • Branch: Clients/CLIENT1/Uat - Client specific Uat config for the client's UAT environment
  • Branch: Clients/CLIENT2/Prod - Client specifc Prod config for the client's PROD environment

Documentation: The "test"

  • Create a DevBase branch with a config file
  • Create a UatBase branch - from the dev branch
  • Make mods to Dev, merge each to Uat
  • Verify Dev and Uat are in sync (nothing to merge. No ghost merges)
  • Create 5 clients. Make Uat and Prod branches for each
  • ====> Every week - add new client - migrate from Uat and create prod
  • Week 1 - Make changes to dev. Merge all to Uat
  • Week 2 - Make changes to dev. Merge all to Uat
  • Verify dev and uat are "in sync"
  • Roll out all changes to all client's uat and prod
  • Verify dev and uat are "in sync"
  • Week 3 - Make changes to dev. Merge all to Uat
  • Week 4 - Make changes to dev. Merge all to Uat
  • Verify dev and uat are "in sync"
  • Roll out all changes to even indexed client's uat and prod
  • Week 5 - Make changes to dev. Merge all to Uat
  • Week 6 - Make changes to dev. Merge all to Uat
  • Verify dev and uat are "in sync"
  • Roll out all changes to odd indexed client's uat and prod
  • Week 7 - Make changes to dev. Merge all to Uat
  • Week 8 - Make changes to dev. Merge all to Uat
  • Verify dev and uat are "in sync"
  • Roll out all changes to all client's uat and prod
  • Verify dev and uat are "in sync"
  • Make a change in one client (random indexed) prod file
  • Merge change to client's uat
  • Merge change to uat base
  • Merge change to dev base
  • Start from week 1
  • Run the above 500 times

About

Testing arbitrary merges across branches to prove a version control system can handle years of changes across branches!

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages

  • Shell 100.0%