Automated merging lab
• Mark Eschbach
As apart of the continous deployment systems I’m responsible for they need to merge changes from stablzing branches towards the less stable branches. We found this greatly reduces the amount of busy work for moving patch sets around. Hopefully few changes are made during the stalbization process; but realisticly we don’t know about some defects until we test all the integrated chnages. I’m a strong adovcate against the Git FLow since the workflow feels the opposite of what I’ve seen done in practice. I hope I remember to record those opinions one day so I can look at how stupid or smart I was.
Anyway, currently we maintain multiple copies of the same core library which is responsible for the automated verification using unit tests, merging, and deploying code across our two primary systesm. For Django this was a rather simple implementation as we have a special file which contains the version number which no one needs to touch. Even I haven’t had need to touch the file since the system stablized. For our Xcode based project this is unforunately a much different project. Verison numbers for the Apple systems are stored in your Info.plist
file along with queit a bit of other information.
When we decide to cut a new release candidate branch the minor verison is incremented. This scheme works really well as the commit to chnage the version number is properly merged. For each hotfix release there after the micro version is then incremented. This scheme hasn’t worked so well. The micro version causes version conflicts because both branches have modified the same line. I came up with a way to fix this using one additional commit in addition to the merge commit, however I would like a more efficient implementation. The current feedback cycle needs to be optimized and the library really needs to be extracted. So here goes on the extraction first.
The core library is composed of primarily shell scripts, something I’m not sure if I regret yet. I might after this. But it’s been an evovling monster.
The core feature of the extraction is the ability to test techniques quickly and verify the work instead of polluting production repositories. Everyone needs a development environment. My first thoughts on organization will have the following directories:
lib
- Contains the library codetests/{test-case}/run
- Exercise the subject under test by manipulating the repositorytests/{test-case}/verify
- Verify the manipulation occured as intendedtests/{test-case}/repo.tgz
- A Git repository to extract the inital state from
First up is probably populating the lib
directory. Done! Going forward I might want ot break the file up based on function. The only drawback I see for that approach is keeping ordering as the number of files grow. Perhaps setupa series of directories to indicate phase? Feels like dealing with the linker while building the microkernel again (good times).
Alrighty, after being pulled to work on some other things I’ll have to come back to this later.