Problems •We cannot move all projects to GHE • We have over 700 repositories • To choose projects to move is difficult and boring... •Some teams do not want GHE
developer git push Hatena Repos GHE ghm (later) Web Hook call git remote update replace all refs by git remote update Mirrors changes on GHE to Hatena’s Repos
Setting up Mirroring 1.Register Hatena repos and GHE repos as a Mirroring Pair 2.Set mirroring config to Hatena repos 3.Set push-denial hook to Hatena repos 4.Register WebHook for mirroring to GHE repos
ghm •in-house Web Application for mirroring pairs management • Stores mirroring pairs • Has WebHook API that invoke mirroring (later) • Provides some APIs
2. Set mirroring config to Hatena repos • refs/ on the remote will be directly mirrored into refs/ → “git remote update“ replaces everything under refs/ by GHE repos’s refs/ • This is the same as “git clone --mirror”
• “git remote update” destroy changes in dst repos(Hatena repos) • Confirm the repos has mirroring config at pre- receive hook by ghm API 3. Set push-denial hook to Hatena repos
http://ghm/api/repos?mirror=projects/Hatena-Bookmark HINSFQPT"1* Returns repos info if the repos pair is registered.
Goals & Solutions •Both GHE and existing repos can be used for production. → mirroring •Anyone can start using GHE easily → git-hatena •GHE failure should not cause to stop deployment. → mirroring, rich server
Dev flow workshop (in-house) •We are GHE newbies •Sharing the workflow of development • from spec definition to production release • Issues, Pull Request, Code Review, Test, CI, deploy, etc...
Conclusion •git and Hatena • We are heavy git users • 700 over repositories •Environment for Gradual Switches • Mirroring (ghm) • Automation tool (git-hatena) • High-spec server •GHE and Hatena