
Ask HN: What's your Git workflow for production systems? - whitepoplar
Hi HN, I&#x27;m revisiting the topic of choosing the best git workflow. To those of you who run software in production, what works best for you? Given the preceding sentence, what&#x27;s the structure of your team?
======
atsaloli
You may find GitLab's proposal of interest.
[https://about.gitlab.com/2016/07/27/the-11-rules-of-
gitlab-f...](https://about.gitlab.com/2016/07/27/the-11-rules-of-gitlab-flow/)

~~~
w4tson
That's interesting. Instead of step 7. we have a separate release CI job which
when is a one click, test build tag release.

This outputs artifacts to a sonatype nexus repo. From there, the binary can be
promoted either automatically or manually to various environments.

It breaks Gitlabs rules of CI modifying the repo (with no explanation) but it
allows any developer with any level of experience to easily release the
product

------
paulddraper
Git Flow is popular
[https://datasift.github.io/gitflow/IntroducingGitFlow.html](https://datasift.github.io/gitflow/IntroducingGitFlow.html)

Trunk-based is IMO the best [http://paulhammant.com/2013/04/05/what-is-trunk-
based-develo...](http://paulhammant.com/2013/04/05/what-is-trunk-based-
development/)

------
nameless912
My git "workflow" (if you can call it that) is to explicitly ban git from
production systems. If your prod machine requires Git to get code, you're
probably doing something wrong. Config files are better gotten from an HTTP
API, where you can audit access; actual code/program files are better grabbed
from something like Artifactory or a network share.

~~~
shaftway
I don't think it's all that bad, especially not for a small shop. I mean,
obvious caveats aside. Don't store sensitive stuff like passwords in git,
don't store big files.

But it does provide a pretty simple clean deploy, with information about the
state of your deployment. You can even include some of that audit support with
some relatively simple, judicious scripts. Check out, echo something to a log
file, commit it to a deployment branch and push it.

I'm not sure I see how network shares or an http API offer better access
controls over a git repo loaded over https for loading up code.

------
EnderMB
I work in a small agency (5 devs), and we use git flow.

Essentially, we perform builds from dev, release branches, and master (and
hotfix, but this rarely ever happens), and move to these branches over a two
week sprint cycle. We work on dev during the sprint, move to a release branch
when we're preparing for a client-facing release, and when the sprint is over
we merge into master, perform our final regression tests and tag the release
with the sprint version number (GitVersion helps a ton for this).

The key point for our production process is that a single build is used to go
between environments. We use Octopus Deploy to package up our build and to
perform the necessary transforms for deploying to different environments.

------
segmondy
In my opinion, your git workflow should be based on your release, application
support & team structure.

If you have just 1 team, releasing 1 version, say a web application then your
workflow will differ from 1 team, maintaining multiple versions of the same
app, say a desktop version or say multiple teams working on one app say an
enterprise backend. I look at how the application has to be released, how the
team is structured, then figure out which workflow we will use.

------
prodigal_erik
Master is the latest stable release. Topics are branched from master. A
release branch is master plus topics that are ready to go live.

Releases are OS packages (.deb, .rpm, whatever) built from release branches.
We don't deploy with git because we don't commit binaries, and git doesn't
know how to deploy our OS dependencies and drain and restart our prod
services.

------
sprobertson
I like a branch per environment, usually staging and production with master as
the development branch. To deploy you push to the environment branch and
webhooks trigger the rest. I'm not sure how to enforce this part, but you
always make sure tests pass on master, merge with staging and make sure they
pass there, then merge with production.

