When Gitflow Stops Being Agile
NOTE: this is a re-post of an original article by Kevin Brandon which disappeared but needs to be preserved as it changed many teams’ perceptions of Gitflow usage in relation to Agile
If you’re in technology and haven’t been living under a rock you’re aware of Git. If you’re aware of Git then you’re probably aware of Vincent Driesson’s eventful blog “A Successful Git Branching Model” that has since been implemented and widely referred to as Gitflow. Don’t let the title of this blog fool you, I don’t have a beef with Gitflow. Vincent was accurate to claim he had a successful Git Branching Model. It gets you there 99% of the time for the majority of teams. Still, I have found as far as a team’s ability to be agile, the prescribed flow can run you a foul when indecisive chickens come home to roost.
In Agile the chickens (the customers and executive management) can sometimes interfere (that’s life/reality). For the sake of this post, I am speaking to when executive management promises a feature that was demoed and they want it out yesterday. The problem is they don’t like the other feature(s) that were also in the build. They want it now, if not yesterday. You could argue semantics of implementing agile here; but, at this point “Agile” has left the building and we need to be agile in the original definition of the word. In my experience it is at this point you suck it up and do as you’re told to those whom provide you a paycheck. So you set off to get an artifact of exactly what the chickens want.
Well, if you have been exercising Gitflow, you had N+1 number of feature branches and of which several have been reviewed and approved into the develop branch. The problem is after that demo, the big chicken in the corner laid and egg and said “LOVE IT” but I don’t like the N-1 other features. Your product owner is crumbling and they are chanting what that chicken wants. Now you are faced with cherry picking commits and analyzing merges with unwanted features.
A successful solution to this problem involves some slight modifications to Gitflow. I don’t know if I can be as so brazen to say maybe Git Flow 2.0? But this has proven itself to work and if it helps the pigs, all the better!
Several big differences here:
- No notion of a “future feature branch”. Let’s face it, all features are future branches until someone in a higher pay grade blesses it to life. Until then any mitigating/mingling with another feature is a risk of feature entanglement.
- Master branch is back to being the source of origin. Gitflow made develop a first class citizen. develop really is a place we want to have immediate integration of our features. We want to have immediate feedback of our conflicts and a place to demo.
- develop in this flow is best to be automatically merged once the feature branch is mergeable and passes all unit tests.
- Special mitigation branches “develop/proj-1” in orange. Here the feature/Proj-1 had a conflict. Rather than resolving the conflict in the develop branch or feature/proj-1 branch, the mitigation is stored separate for future reference. Once the mitigation is made it is pulled into develop. This is key to keeping your features de-tangled.
- develop should never be directly updated by anyone other than your CI server.
- develop can be at any time destroyed and rebuilt from available features.
- Feature branches are only branched from master, never from develop. This is important again to keep us premature exposure to another feature.
- Releases are made from approved features… not the develop branch… not integration.
Overall this modification to gitflow provides immediate integration feedback, firewalls CI from the world, keeps features detangled, your code review doesn’t inhibit integration, and lets you create releases from chicken approved features. Now that’s keeping Agile to its original roots of being an adjective!
UPDATE (April 20, 2021): folks have continued to consider more streamlined DevOps code delivery workflows, to the point that Vincent Driesson himself (who coined the term and approach for “gitflow”) has all but disavowed its strict adherence in an Agile setting with his May 2020 update, suggesting consideration of trunk-based development, Enhanced gitlfow and/or further simplified “GitHub feature branch” flows.
Continuous Testing and Shift-Left roadblocks in enterprise
This one goes out to all those stubborn QA Testers, “Business Users” & User Acceptance Testing (UAT) leads who insist on “waiting until everything’s 100% done” to even start writing Test Cases or carrying out time-consuming manual test scenarios which they undoubtedly repeat every time they need to test anything, all the while resisting “Shift-Left/Shift-Right” principles like Continuous Testing, Acceptance Criteria as test cases, and Test recording & automation/scripting for repetitive test tasks. Likewise it goes out to all those executives who take an indifferent approach to quality, ripe with understaffed QA departments that lets them continue to own corporate application sign-off and define testing practices, all while (quite inadvertently and often unbeknownst to them) acting as the primary bottleneck to delivery.
HTML Tutorial and Web History lesson
Today, something unexpected happened. I had the (somewhat unplanned and impromptu) pleasure of showing the ropes to the “new recruit” at work, a student here for a work term over summer break.
Now, we’re not necessarily doing that much coding here yet, as we’re still in the process of bringing back large portions of IT functionality in-house. We do, however, do a lot of software configuration, release management, testing/QA tasks, and, we are ramping up to use a major enterprise CMS to be able to create front-end content quickly (HTML/JS/CSS backed by JSP & EJB following OSGI structure).
I’ve always wondered in the back of my mind, if I were “in charge”, how would I more gently introduce the younger generation to the world of “enterprise programming”? Certainly the “enterprise world” is often significantly different, if not completely far-removed, from the real-world of cutting edge software development based on agile methodologies and lightweight web frameworks, co-developed with the customer in real-time, or implemented competitively overnight at a weekend hackathon. It is also far-removed from the naiively specialized world of “academic coding”, where “programming problems” (albeit sometimes very tricky ones) are assigned with a very clear set of up-front requirements and well-defined metrics for acceptance, where every assignment is given a certain amount of time to complete and graded for completeness and of course for “originality” or “ability-to-follow-the-book-without-copying” (where copying any minor component is seen as the devil’s work, labelled plagiarism, and ostracized).
Enterprise application development on the other hand, often times has no clear-cut requirements, no well-defined acceptance criteria (other than customer happiness) and is both behind schedule and over-budget before coding even begins. That thing about the no copying? Yeah that’s tossed out the window in favour of cutting corners and “getting it to market” as quickly as possible, often at the expense of quality (or in some cases even the development team understanding the solution, the most recent case that comes to mind is this hilarious StackOverflow verbatim copy “programming faux pas” from a Nissan connected car developer). All that being said, enterprise application development isn’t that hard, just more complex and frustrating than greenfielding, open source work, or even consulting. So it turned out to be a good opportunity to take a stab at it, as the student in question only had a year of Computer Science so far and despite some exposure to Java had not much in the way of Web development yet as those courses were coming later in the program. He did however, have a healthy interest in the Gaming industry, an industry which is increasingly finding an audience and monetization options for its wares on Mobile and Web platforms.
“The only thing constant is change”
Dusting off my 2008 cover letter to RIM on BlackBerry’s future, rejected job application
The Research in Motion headquarters, based in Waterloo, Ontario, Canada (Photo credit: Wikipedia)
While backing up some files to an external hard drive from my older one, I recently came across an old Cover Letter which had accompanied my resume in a job application I sent to Research In Motion (RIM) back in Summer of 2008.
It’s interesting to look back at, because I recall back then being very frustrated with the state of the Mobile industry in North America (particularly in Canada). These feelings were only magnified by my time spent in Japan 2006-2008, a country which at that time was a clear leader in Mobile technologies and in the global consumer electronics in general. Since then, Korea and China (two other countries I was fortunate enough to have spent some time in during my Graduate school vacations in between terms) have now caught up in terms of innovation and even surpassed Japan’s leading Mobile technology companies in sales as well.
Back then companies (again particularly China & Korea but many European firms as well) were sending some of their top experts and technologists to Japan to do market research with and/or attempt to poach talented Japanese engineers from, the likes of world leading Japanese tech companies: Sony-Ericsson, Panasonic, Sharp, Toshiba, Hitachi, Mitsubishi, Fujitsu, Fuji-Xerox, Konica-Minolta, Nintendo, Softbank, NTT, KDDI, etc. The goal was of course to glean as much information and consumer insights as possible from the country which boasted the fastest home fiber internet speeds, mobile internet speeds, mobile data usage, and mobile revenue per unit (ARPU) in not just gaming which usually comes to mind when thinking of Japan, but all application sectors.
My experience in Japan indeed taught me a thing or two about “sticky” services, particularly the infamous “iMode business model” by Takeshi Natsuno of NTT DoCoMo which succeeded by providing a cohesive ecosystem of applications and a flat-rate (about $40 USD/month) unlimited data service, which drove subscriptions through the roof. On top of this, standards and specifications which were simple to follow for developers and which reduced page-size for web content with cHTML then later WAP/WML helped grow the service’s offerings in an organic way. Only now are we starting to see the same sorts of initiatives by Google [LINK] & Apple [LINK] in North America. Over here, very little regard has been made for how to optimize mobile services for users, which is why our Mobile industry is only now catching up to and finally surpassing where Japan was 9-10 years ago. Indeed, we constantly hear reports about the growth of Online/Mobile Video (i.e. streaming ad-supported content like YouTube, Vimeo, etc), On-Demand/IPTV (i.e. rentals or purchases on iTunes, GooglePlay, etc), and OTT (i.e. subscription services like Netflix, Hulu & Amazon Prime Instant Video). However, MobileTV via OneSeg had already reached millions of users whereas SMS texting was just starting to take off in North America (in any meaningful way that resembles its adoption level today).
Birth of Reiko Clara Copeland
A very special yet belated birthday welcome goes out to Reiko Clara Copeland, the newest and youngest member of the BCmoney family.
Being due today – but arriving over a week early at approximately 8:20pm AST on Thursday, April 29th, 2015 – my daughter and second child Reiko Clara Copeland was born a healthy 3.03 kilograms (6 pounds 11 ounces) to Bryan Copeland and Nana (Kurata) Copeland. She was delivered safely at the maternity ward of the Moncton Hospital after a roughly 30 minute, and almost pain-free (compared to the first one according to my wife) delivery.
Rockin’ the “Bad to the Bone” shades her brother rocked before her…
BC$ = Behavior, Content, Money
The goal of the BC$ project is to raise awareness and make changes with respect to the three pillars of information freedom - Behavior (pursuit of interests and passions), Content (sharing/exchanging ideas in various formats), Money (fairness and accessibility) - bringing to light the fact that:
1. We regularly hand over our browser histories, search histories and daily online activities to companies that want our money, or, to benefit from our use of their services with lucrative ad deals or sales of personal information.
2. We create and/or consume interesting content on their services, but we aren't adequately rewarded for our creative efforts or loyalty.
3. We pay money to be connected online (and possibly also over mobile), yet we lose both time and money by allowing companies to market to us with unsolicited advertisements, irrelevant product offers and unfairly structured service pricing plans.