If your team uses Git and Continuous Integration, chances are good that your workflow could benefit from
git greenbase. But first, strap on your VR headset and experience the perils of
git pull through the eyes of our seasoned developer, Karen.
You arrive to work still flush with exertion from your morning run, a smile on your face and a bounce in your step — the light bulb went off mid run: you knew why the identity service was flaking out every morning at 11:48AM. Firing up the console, you
cd to the right repo and
git pull flows nimbly from your fingertips, your heel tapping out the beat to the last song on your playlist; it was a good one.
Git decides it needs to repack and take out the garbage on your oversized repo. You roll your eyes slightly, but no bother — nothing can get you down today. You’re in and out of Vim in a flash. Hard to believe such a simple three-line change would alleviate so much misery for the Ops peeps. You glance at the clock. It just might be possible to get it diffed to code review before the daily standup. Just one thing left to do… Run the tests.
“That’s funny… 17 tests failed???” You furrow your brow in consternation. “How did my change possibly break the Time widget”, you think, shaking your head. Down below, your once merry foot had stopped tapping, its good beats forgotten.
The next ten minutes sneak past you like a puma as you pour over all the source files even remotely related to your fix. Still nothing. A blip on the screen shocks you from your concentration like a cold pie to the face. “You coming to the standup?” Yikes, I’m late!
Skidding to a halt Coyote-style near the great semicircle of agility, you sidle up next to your buddy Anne. Everyone looks faintly amused, but they’re not looking at you. Tom is apologizing for breaking the build.
“Sorry I’m late everybody”, you interject meekly. “I was looking at some tests I broke.”
Tom looks at you sheepishly. “By any chance, were they 17 tests in the Time widget?”
Slumping forward, you let out an overly dramatic exasperated sigh of frustration.
The team glances around for a second, then bursts into laughter. It was a knowing laugh, one of commiseration and mutual understanding.
git pullfalls short
What happened to you in our story? You pulled a broken build! That sent you down a rabbit hole searching in vain for a problem you didn’t cause.
git pull to pull in the latest changes, but think about it, did you really want the latest changes? Or did you want the latest good changes? When people build a house, they take time to prepare the land and the foundation. They don’t just start building on a pile of junk. Likewise, when we start development of a new feature or bug fix, we should start from a known good place. That gives you the confidence that any build or test failures really are your fault, and not from Anne, Tom, or that one intern that rides around the office on a unicycle.
If your team practices Continuous Integration (CI) and has a solid suite of automated tests, your source of truth for what constitutes a “known good build” is your CI server.
git greenbaseto the rescue!
This is where
git greenbase comes in. Instead of blindly running
git pull like a slot machine and hoping for the best, you run
git greenbase. It queries your CI server for the latest passing, or “green” build, then resets your local master to match. Voila!
master is now at a known good state. Start your coding engines with confidence!
If you are on a local feature branch that tracks
master, and your team uses a rebase-based workflow, then
git greenbase still resets
master to match the green build, but it also rebases your local feature branch on top of master. Pretty cool, huh?
git greenbase sits serenely on Github: https://github.com/tygerbytes/git-greenbase. If you’re on Linux, install it like this:
git clone https://github.com/tygerbytes/git-greenbase.git cd git-greenbase ./install
./install script will create a symlink to git-greenbase and add it to your PATH. Git will find it in your path and allow you to run
git greenbase, just like any Git command.
(See the repo for the latest installation instructions.)
As of March 2018 git greenbase has only been tested with Linux. It probably works with Mac OS X as well. It most likely won’t work as is on Windows. I am totally open to pull requests. If demand is great enough, I’ll write a version in PowerShell.
git greenbaseto work with your CI provider
Now that it’s installed, how do you configure it to work with your CI provider? Typically you need to provide Git with your CI server’s URL, API token, and the ID of your project. The information is stored in your Git config.
For example, if you use Travis CI, you would run commands similar to the following:
git config greenbase.provider travisci
git config greenbase.travisci.token <TOKEN>
git config greenbase.travisci.serverUri <SERVER_URI>
git config greenbase.travisci.repoId <GITHUB_REPO_ID>
(See the repo for the latest configuration instructions.)
As of March 2018 the only CI providers supported out of the OSS box are:
That’s a short list! If you would like to add support for another CI provider, feel free to send me a pull request. See below under “Contributing to development.”
git greenbase is written in Bash, and tested using the Bats testing framework.
I tried my best to design it in a modular fashion for testability and maintainability. For example, the logic for communicating with each CI provider lives in its own Bash script, with its Bats tests alongside it in the same directory.
Personally, Bash isn’t my favorite language, nor am I a super skilled Bash developer. That said, I feel tools like
git greenbase will bring more peace, love, and butterflies to the DevOps landscape. So I persevere. :)
See the development page for the latest development details.
If you’re super stoked about
git greenbase and all the pain it has saved you and your team, buy me a coffee. I find coffee a great motivator.
Originally published at tygertec.com on March 5, 2018.
Create your free account to unlock your custom reading experience.