3 ms·

Ask HN: What's your Git workflow for production systems?

• nameless912 10y ago
  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 10y ago
    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.
• paulddraper 10y ago
  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-development/ http://paulhammant.com/2013/04/05/what-is-trunk-based-develo...
• segmondy 10y ago
  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.
• atsaloli 10y ago
  You may find GitLab's proposal of interest. https://about.gitlab.com/2016/07/27/the-11-rules-of-gitlab-flow/ https://about.gitlab.com/2016/07/27/the-11-rules-of-gitlab-f...
  • w4tson 10y ago
    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
• sprobertson 10y ago
  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.
• deleted 10y ago
  [deleted]
• prodigal_erik 10y ago
  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.
• EnderMB 10y ago
  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.