![]() With git-flow, you have a develop branch that exists in perpetuity alongside master. I’ve always found it painful due to its needless complexity and its sensitivity to human error. I’ve worked at one or two places that used git-flow. Using a complicated Git workflow like git-flow To summarize: long-lived feature branches make deployments riskier. All the code in my feature branch is “code in development”, so it all counts toward widening dev/prod parity. The delta between production and development is “code in development minus code in production”. I can’t have tight parity between dev and prod if I don’t have tight parity between my master branch and my feature branches. Frequent merging is essential to dev/prod parity Small, frequent deployments make it less likely that any one deployment will be problematic. We do deployments to deliver value to users but also to maintain dev/prod parity. The less frequently deployments are performed, the bigger the opportunity for someone to forget a crucial step in the deployment workflow, for software rot to cause a problem with the deployment mechanisms, or for some other problem to creep in. ![]() The bigger the deployments, the more stuff there is to potentially go wrong. There are practical considerations involved as well.Įvery deployment carries a risk of introducing a problem. This is true, but all by itself, it’s overly simplistic. On the surface, it seems like the reason for deploying is to deliver new value (features and bugfixes) to users. Deployments aren’t just for shipping code Let’s talk about the reasons for merging and deploying. The way a team handles deployments has a bearing on how it uses Git and vice versa. Git workflows and deployment workflows are inextricably linked. Misunderstanding the reasons for merging and deploying But using feature flags is less time-consuming than dealing with all the problems introduced by long-lived feature branches. It’s more tedious and time-consuming to use feature flags than to not. It’s true that using feature flags adds overhead. Toggle the feature flag “on” to surface the feature to users.Build the UI for the feature, but put the UI behind a feature flag, then merge and deploy.not the UI) for the feature, then merge and deploy creation of new database tables, etc.), then merge and deploy Perform the foundational work for the feature (e.g.In my experience it’s always possible to work in a sequence more or less like this: I’ve never seen this problem stand up to an intelligent use of feature flags and a judicious sequencing of the coding work. ![]() Sometimes it seems that a long-lived branch is necessary because the feature is irreducibly large and the feature can’t be released to users until it’s all the way done. Upstream cause: ignorance of feature flags If there’s not a super clear answer to the question, “How exactly do we know when this feature is done?” then it’s a sign the story isn’t “shovel-ready” and that it should be clarified more before someone starts working on it. In my experience programmers and team leaders are often bad about letting user stories through that are too big and too nebulously-defined. ![]() ![]() Upstream cause: feature was too bigĪ very common cause of a branch that’s too big is a feature that was too big. Now let’s talk about some of the upstream causes of overly long/large feature branches. The more stuff there is to review, the harder it is to review it. The longer a feature branch lives, a) the more code there will be to merge and b) the more opportunity the master branch will have had to get out of sync with the feature branch. My feature branches tend to last less than one day because often the entire cycle of coding, review, deployment and verification all happens inside of one day. The longer a branch lives, the more likely it is that there will be certain problems, discussed below. I don’t like feature branches to last for more than a few days. For example, what’s appropriate for a 20-person team isn’t appropriate for a solo developer. These are just some of the common ones I’ve come across.Īnd as a side note: I firmly believe that the workflows I describe in the post are the best way to do things most of the time, but at the same time I know that there’s almost never a right answer that applies to everything all the time. This is not meant to be an exhaustive list. Here are some Git workflow anti-patterns I’ve observed in my career. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |