If you're using GitFlow I feel bad for you, son (or woman)

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

I got 99 problems but my branching strategy ain’t one.

Editors - you deleted the first line?
Which kinda ruins the rhyme.

It started “If you’re still using GitFlow I feel bad for you son (or woman)…
I got 99 problems…”

The dashboard no longer shows me articles I’ve published or gives any way to edit them.

I thought my title was better - not sure why it was changed.

1 Like

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?

I enabled previous title

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.

1 Like

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

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

1 Like

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.

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.

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

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.

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!

1 Like

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!