Succeeding at Devops with Git and a Monorepo: Your questions answered
Thank you to everyone who joined us for our live webinar "Git in the Enterprise: How to Succeed at DevOps using Git and a Monorepo." We really enjoyed presenting with our partners over at GitLab, and were lucky to have such an enthusiastic audience.
If you missed the webinar, watch the on-demand version at a time that works for you.
During the broadcast, GitLab VP of Product Job van der Voort and I answered as many questions as possible, but we wanted to take the time to answer a few more of the compelling inquiries that came in from our live audience.
With that, off to the questions!
Q: Is it possible to set up a separate repo, which could build all these other repos into one or more Docker containers to run those tests?
Answer from Matt Attaway, Perforce:
Yes, but it’s not easy to get them from a specific point in time where they were "shipped," and a single push may include commits in various states of disrepair. Frequently, only the tip commit of that push passes the tests. Taking a slice by time may grab commits that will not work, and are not expected to work.
However, when GitSwarm pushes into the Helix monorepo it marks the final commit of a push with a special tag so you know it is a good candidate for automated testing.
GitSwarm would be perfect for this use case. You can pull different paths from across multiple depots together into one Git repository. Commits to the Git repository would then be replicated into Helix Versioning Engine, and vice versa. Developers on either side will see each other’s changes, but can use whichever tool they prefer.
Q: Referring to slide 28 (pictured below), which tool is being shown that only merges a merge request after the tests have passed? And what did you mean by "merge?" Do you mean auto-integration and then submit, or simply auto-integration? After the review and the CI passed usually the repo has moved on. Thus how can the auto-merge take place?
In GitLab you can use the "Merge when build succeeds" to merge code automatically after your continuous integration build has completed successfully. GitLab can merge using different strategies. In most circumstances, it merges using a merge commit.
However, in GitLab Enterprise Edition you have the option to merge using the fast-forward strategy or even rebase code before it gets merged. The only limitation that this has is the repository might have new commits added in front. GitLab will still perform the merge successfully if possible (independent of the strategy), but the combination of new code and your source branch might not have been tested.
That being said, GitLab automatically tests any new commits on your default branch, which should give you feedback immediately on the status post-merge. This allows you to move forward faster than retesting the merge request before merging every time a new commit comes in.
GitLab has extensive code reviewing capabilities built-in, but if you want it to integrate with other tools, it will work together wonderfully with any tool using Git. In addition, GitLab has a full API that allows you to integrate it easily with your favorite tools.
Again, thank you to everyone who joined us live, and if you missed the broadcast be sure to check out our presentation on how to succeed in DevOps with Git and a monorep on-demand here.