GitHub Flow
scottchacon.com
GitHub Flow
1–10 of 66 posts
Re: GitHub Flow
#2I wasn't aware that you can open pull requests from within the same project (i.e. not from a fork). The idea of using this for quick code reviews before merging code into the production branch is really interesting to me...
Re: GitHub Flow
#3Well written and presented. Important not to miss out his closing comment:
"For teams that have to do formal releases on a longer term interval (a few weeks to a few months between releases), and be able to do hot-fixes and maintenance branches and other things that arise from shipping so infrequently, git-flow makes sense and I would highly advocate it’s use.
For teams that have set up a culture of shipping, who push to production every day, who are constantly testing and deploying, I would advocate picking something simpler like GitHub Flow."
So if you fall in the second category, this is a read for you.
Re: GitHub Flow
#4Is it really zero-downtime deployment? I've read about Passenger 3's zero-downtime deployment strategy, but on my Passenger 3 setup, the server is still always a little unresponsive for a few seconds after a restart.
Re: GitHub Flow
#5"Every branch we push has tests run on it and reported into the chat room, so if you haven’t run them locally, you can simply push to a topic branch (even a branch with a single commit) on the server and wait for Jenkins to tell you if it passes everything."
From this, it sounds like Jenkins is automatically picking up new topic branches, running the tests, and reporting on the results. Any suggestions on how to set something like this up? In my (very limited) experience with Hudson/Jenkins, this sounds like it wouldn't be possible without manually setting up a project for each branch.
Re: GitHub Flow
#6Very good comparison between workflows of deploying several times per day versus much less often. While it might not be obvious to some, the exact same git "flow" won't work for both. Your tools should complement your corporate culture, not the other way around.
I think the most important thing to note from either method, though, is not to develop on master/trunk. Have a separate branch, or further branches off an entire "develop" branch. The tip of master should always be a stable build.
Re: GitHub Flow
#7Is it really zero-downtime deployment? I've read about Passenger 3's zero-downtime deployment strategy, but on my Passenger 3 setup, the server is still always a little unresponsive for a few seconds after a restart.
github uses unicorn behind nginx.
Re: GitHub Flow
#8Is it really zero-downtime deployment? I've read about Passenger 3's zero-downtime deployment strategy, but on my Passenger 3 setup, the server is still always a little unresponsive for a few seconds after a restart.
As far as I know, they're using Unicorn: https://github.com/blog/517-unicorn
They spin up new instances of the app and let the old instances finish serving requests before killing them.
Re: GitHub Flow
#9Is it really zero-downtime deployment? I've read about Passenger 3's zero-downtime deployment strategy, but on my Passenger 3 setup, the server is still always a little unresponsive for a few seconds after a restart.
I don't know how it works in the Rails deployment world, but for us Python/Django folks all we have to do is touch a wsgi file and/or do a soft reload of the web server for changes to be picked up, and they do so instantly. No downtime. Until then, even if files are replaced, the old site gets served (although I would recommend symlinking instead of flat-out replacing files and directories).
Re: GitHub Flow
#10One question i've always had: How often do "regular" people commit? Should I be committing every time I hit save... or should I wait? (I don't work in a dev team, so I'm looking for the wisdom of developers who have to work in teams.)