#22.6 TBD 讀網站會 - Continuous Integration (CI) 下篇

--- title: "#22.6 TBD 讀網站會 - Continuous Integration (CI) 下篇" tags: Meetups date: 2022-07-07 --- [Link](https://trunkbaseddevelopment.com/continuous-integration/#master--slave-ci-infrastructure) ### The high bar, today Highest throughput teams have CI server setups that prevent breakage of the trunk. That means that commits are verified before they land in the trunk to the extent where teammates can update/sync/pull. The problem this solves is when the rate of commit into the trunk would be too high to have an auto-rollback on build failure. In Google one commit lands in the trunk every 30 seconds. Few CI technologies (and source control systems) can keep up with that in a way that is not batching (to some degree of interpretation). You’d be stopping the line too often for humans to make sense of a train wreck of red builds, where only one two were actual breakages rather than just bad timing. It would not be computationally hard to recreate a last-green-plus-this-commit contrived HEAD to verify a commit in isolation to the other 20 that arrived in the last ten minutes, but that would be a crazy amount of computing power to do so. Better to marshal the pending commit in a place where it looks like it is immediately following a previously known green (passing) commit and is not yet on the shared trunk. That place has a name - a branch (or a branch of a fork the GitHub way). It is a perfect place to CI verify the commit before auto-merging it to the shared trunk (if you want to auto-merge after code review approvals). The new problem is how do you prevent that short-lived feature branch from sleepwalking into a long-lived feature branch with half a dozen developers keeping it from being ‘complete’ (somehow) and merged back. You cannot with tools today, but it would be cool if you could have a ticking clock or count down on those branches at creation to enforce its ‘temporary’ intention. Refer to Game Changers - Google Home Grown CI and Tooling for more information on the high commit rate CI stuff. Note too that they do not have a temp branch set up to facilitate that. ## Industry CI daemon confusion ThoughtWorks commissioned a survey - “No One Agrees How to Define CI or CD". That the hypothesis of Continuous Integration being thought of as compatible with branching models other than Trunk-Based Development was, unfortunately, shown to be true. Their chief scientist, Martin Fowler, writes about the general effect in his “[Semantic Diffusion](https://martinfowler.com/bliki/SemanticDiffusion.html)” article. Martin also wrote specifically on the lamentable pat on the back that multi-active-branch teams give themselves when they set up a CI server/daemon for one or all of those branches: “Continuous Integration Certification” and within that a great coin “Daemonic Continuous Integration” for this effect. > **This site's use of CI and Trunk-Based Development** > Given other popular branching models (that are not Trunk-Based Development) also benefit from CI servers watching for and verifying commits, this site is going to refer to the commit to a *enforced single shared source-control branch practice as Trunk-Based Development. There are many CI technologies and services available for teams to use. Some are free, and some are open source. Some store the configuration for a pipeline in VCS, and some store it somewhere else. In order to more smoothly support branch for release, the best CI solutions co-locate the configuration for a pipeline in the same branch too. ## Server/daemon implementations Jenkins commercial service, for Jenkins Open Source - on-premises installable Travis-CI - cloud Circle-CI - cloud ThoughtWorks' Go CD - cloud and on-premises install Codeship - cloud Atlassian’s Bamboo - on-premises install JetBrains' TeamCity - on-premises install Microsoft’s TFS platform - on-premises install (built into larger platform) Codefresh - cloud, on-premises and hybrid (bring your own runner) install Note, for Jenkins, you can now use Pipeline DSL scripts (or Groovy) (formerly Workflow), or you can use Jenkins with GroupOn’s DotCI to co-locate the config with the thing being built/verified in source-control.