Patrick Lee Scott

Read my story at https://patscott.io/

If you’re still using GitFlow I feel bad for you son (or woman)

I got 99 problems but my branching strategy ain't one.
Back in the year of 2017.
I wrote an article that to some seemed like a dream.
I said I commit to master, and I still do.
It's been a few years and now you should, too.
"But how do I deploy to staging?" you might declare,
"not using GitFlow seems unfair!"
Don't despair!
Don't despair!
I'll show you how to turn the implicit into the explicit
simplifying your workflow so you can finish it
Instead of representing environments using branches
you create artifacts using Helm and then schedule the advancements
just create a pull request to your codified environment
then just wait for JX to do the rest
Instead of keeping a mental map of loosely defined entries
you're permanent environments will be tersely defined dependencies.
Making implicit concepts explicit is the thing to do!
To get away from GitFlow I codify my environments and you should too!

Tags

Comments

November 2nd, 2019

Hi Patrick - we decided to change the title - I was very confused - because i don’t know Jay-z song.
Should I update it back?

November 2nd, 2019

I enabled previous title

November 2nd, 2019

Thanks!

Analytics or split-testing on titles would be nice. Perhaps more people don’t get it? Or perhaps it invokes curiosity?

Only the data knows.

November 2nd, 2019

yes, sure - it can be nice feature - because it’s hard to understand what is going on with this story :slight_smile: maybe few sentences before lyrics will help to get into it

November 8th, 2019

I don’t get it. What is wrong/hard about gitflow? Why is “codifying the environment” better? It sounds complicated. gitflow is simple.

November 13th, 2019

gitflow relies on implicitly defined concepts that need to be kept track of essentially in everyone’s head.

and it may seem simple with one or two projects, but by the time you get to several to dozens of services it’s absolute madness.

Instead, committing to master results in a release of an artifact, and then your environments can be represented by a simple dependency tree, like so:


dependencies:
- name: dashboard
  repository: http://jenkins-x-chartmuseum:8080
  version: 1.6.9
- alias: expose
  name: exposecontroller
  repository: http://chartmuseum.jenkins-x.io
  version: 2.3.112
- alias: cleanup
  name: exposecontroller
  repository: http://chartmuseum.jenkins-x.io
  version: 2.3.112
- name: server
  repository: http://jenkins-x-chartmuseum:8080
  version: 3.13.16
- alias: server-db
  name: postgresql
  repository: https://kubernetes-charts.storage.googleapis.com/
  version: 6.3.4
- alias: server-reporting-db
  name: postgresql
  repository: https://kubernetes-charts.storage.googleapis.com/
  version: 6.3.4

No more implicit concepts, and an auditable, reviewable changelog of every modification to an environment.

November 13th, 2019

I used gitflow for years, so I used to think it was useful too. There’s just better, more repeatable, more auditable, more explicit, less implicit, and easier ways.

To get all of the above benefits may seem like a lot to set up, but if you use JX it comes this way out of the box.

November 13th, 2019

furthermore, then you can start using feature branches for feature flags instead of coding it into your application

November 13th, 2019

Are you comparing this to attempting to use gitflow on multiple git repos for interdependent projects that are deployed in a single “environment”? If so, I agree that is madness. We house all of our projects (10+ front end and back end projects) that are deployed to a single Kubernetes cluster in a single mono-repo and gitflow works really well. Moving to a mono-repo was a life saver.

By building the dev environment from the develop branch and production from the master branch, gitflow is not just an implicit concept, but rather quite explicit. How does this approach with artifacts deal with this? How do you know what code is in what environment?

I admit that I don’t totally understand what you are talking about with this release artifact concept, and am still hoping for an “aha” moment that will make me want to embrace this idea.

November 13th, 2019

I mean I’m pretty loudly and adamantly against monorepos too haha

much easier to have each app be responsible for themselves, though, without releases/artifacts to compose them together again that is difficult.

What about databases that aren’t part of your code base? Configmaps? Secrets?

What if you want to add a new environment - like demo - or test-x? You add more branches then remember branch x maps to environment y? I just create a new “requirements.yaml” file.

What if you want to create ten new environments? ten more branches?

Each artifact is versioned and release to a repository, as well as tagged in github and logged into the releases tab with what changes are in each release. You can see the code for each version by clicking “releases” and looking at the list.

Yea, my rap didn’t really get into that lol.

I’ll write more about it soon!

November 13th, 2019

I mean I’m pretty loudly and adamantly against monorepos too haha
…much easier to have each app be responsible for themselves, though, without releases/artifacts to compose them together again that is difficult.

There may be tools and solutions to help make it work that with multi-repos, but I have to tell you that switching from multi-repos to a mono-repo saved my last project from utter chaos. And that all “the big guys” use mono repo gave me the confidence to make the switch, and that goodness I did. Having one place to go to so see what my entire distributed team has been up to do is invaluable. Anyway, a debate for another day.

I’m starting to think the next thing you are going to tell me is to use tabs instead of spaces. Never! :slight_smile:

What about databases that aren’t part of your code base? Configmaps? Secrets?

Databases are a problem, no doubt!!! If you solution solves this, I’m looking forward to reading about it.

What if you want to add a new environment - like demo - or test-x? You add more branches then remember branch x maps to environment y? I just create a new “requirements.yaml” file.
What if you want to create ten new environments? ten more branches?

I haven’t come across a need or desire for 10 environments. But yes, new environments would be built from branches. If I want a demo environment with different code than dev or prod, then I will already have a single branch called in “demo” in my mono-repo. It is hard to imagine what could be more convenient.

Each artifact is versioned and release to a repository, as well as tagged in github and logged into the releases tab with what changes are in each release. You can see the code for each version by clicking “releases” and looking at the list.

Hum, interesting.

Yea, my rap didn’t really get into that lol.
I’ll write more about it soon!

I’m looking forward to it!

More by Patrick Lee Scott

Kubernetes
Softwareengineering
Startup
Jenkins X
Engineering
Kubernetes
Docker
React
Javascript
Docker
Software Architecture
Microservices
Devops
Javascript
React
React
Startup
Microservice Architecture
Microservices
Docker
Topics of interest