But you're not deploying *all* new code every day, right? You're still working on longer-running features that don't get released all at the same time?
The setup I outlines should work for daily (or continuous) deploys as well. Code is committed into a feature branch, once complete and reviewed, gets merged into the 'development' branch. At any given time (and at many given times) the 'development' branch is released. A new release should always be tagged. You don't have to cut a release branch, but having one is a good in-between step that allows for last-minute QA and automated bug detection and resolution... we tend to tag immediately before deploying, since tags are immutable. -- justin On Wed, Sep 21, 2011 at 7:32 AM, Wade Preston Shearer <[email protected]> wrote: > What about for very agile web development? Our development-to-deployment > cycle is generally quite short. If we are deploying new code every day, is a > new branch and tag overkill? > > > On 21 Sep 2011, at 8:01, S. Dale Morrey wrote: > >> A little background. I have worked on teams ranging in size from 1 >> person (just me), to 5,000 in a single org. I've held positions >> ranging from entry level software developer, to lead developer, all >> the way to project manager. >> >> For most of the successful larger teams I've worked on, the process is >> pretty much as you described. >> The difference is subtle and has to do with the way QA is viewed in >> the organization. >> >> Three primary branches are created in the repo, called dev, test and stable. >> >> First the team as a whole develops the acceptance criteria for the >> product they are creating and writes those criteria into tests that >> can verify as much functionality as possible at compile time, these >> are called unit tests. Once the tests are in place, they form the >> basis of the dev and test branches. >> >> The software team then develops source code which will pass the >> compile time testing (or possibly new tests if it's found out the >> acceptance criteria were incorrectly specified), then a patch is >> submitted to the QA branch. >> >> No matter how many people you have, a QA department should handle >> testing the code for anything beyond the initial "compile & pray" >> stage and provide detailed feedback to the developer(s) (although >> generally it will be the team lead) responsible for the source code. >> >> If your organization is just starting out, then your entire QA >> department may in fact be just one guy or gal, may even be you >> yourself but you should treat it mentally as a separate job. >> >> QA's ONLY job is to test against the documented acceptance criteria, >> and either accept or reject it. If you are good at writing your own >> software tests (this includes unit testing but also other tests like >> client/server dummies), then you will generally find your rejections >> are limited to criteria that cannot be easily automated. (In my >> experience those failures are generally against subjective criteria.) >> >> Even though QA can be a completely separate department not affiliated >> with the dev department; I did once work for a company where the QA >> department was comprised primarily of the software development team >> leads and in my opinion this was the most effective setup, since if it >> doesn't work, you're gonna hear about it directly from your boss. >> >> After QA deems that your team's code is fully functional and passes >> all acceptance criteria, a patch is then made and applied from the >> test branch to the stable branch. Since QA are the gatekeepers here >> it's their job to make sure that this part of the process works. >> Since it's an aggregate step instead of a per developer step, it's >> generally successful, and the QA folks are expected to throw the dev >> grunts a pizza party each time this happens :) >> >> Now there are numerous exceptions to this, but most of the truly >> successful organizations I've worked for use this or some variant. >> >> For instance exceptionally large software products, may not have a 1 >> to 1 mapping between dev & qa. Instead they isolate the functionality >> of the product into various domains, each with their own dev teams. >> Then there are aggregate QA teams that handle input from multiple dev >> teams. Hopefully with a final master QA team that includes beta >> testers. >> >> Honestly though, projects of that size and scope will generally be >> enterprise projects that touch on more than just software. In this >> case the project will hopefully have a project manager co-ordinating >> everything and facilitating communication across the vastness of the >> project. >> >> Sincerely, >> Dale >> >> On Wed, Sep 21, 2011 at 2:29 AM, justin <[email protected]> wrote: >>> We use this: >>> >>> http://nvie.com/posts/a-successful-git-branching-model/ >>> >>> This also works really well: >>> >>> http://scottchacon.com/2011/08/31/github-flow.html >>> >>> My team actually uses a bit of a hybrid between the two. We're working >>> toward decoupling features from release dates, and as we do that, we >>> end up moving more toward the "github flow" than gitflow. >>> >>> Our current flow goes something like this: >>> >>> * We have one 'production' branch that contains the codebase which is >>> currently live on our server. >>> >>> * We have a second 'develop' branch which contains the code currently >>> in QA to go live with the next release. >>> >>> * We have any number of 'feature' branches which are currently under >>> development. Right now that number is 40, but that's lower than usual >>> because we cut a release branch this morning and merged down ~45 >>> feature branches. >>> >>> >>> We also might have: >>> >>> * Zero or one 'release/x.y.z' branches. These are a snapshot of >>> develop which undergoes a full manual regression test by our QA team. >>> A release branch is cut every two weeks, and will become our next >>> tagged release and 'production' branch — if and when it has no >>> blocking bugs left. >>> >>> * Zero or one 'hotfix/x.y.z' branches. These branches are very short >>> lived, and only exist as a place to write and test critical bugfixes >>> before merging them into production and deploying. >>> >>> >>> >>> We have matching continuous integration servers for the 'production', >>> 'development' and 'release' branches. Every commit against them is >>> automatically deployed and tested — and results in either a "1-up" or >>> a "Mario died" noise on my computer :) >>> >>> We also have a handful of staging servers (currently between 3 and 5?) >>> which are used to manually test code before it goes out. >>> >>> * The primary staging server is automatically deployed from 'develop' >>> on a given cycle, unless there happens to be an open 'release/x.y.z' >>> branch, in which case it will auto-deploy the release branch instead. >>> >>> * Secondary, tertiary, etc staging servers are available for >>> developers, QA, and other employees to deploy and test arbitrary code >>> on. >>> >>> Right now, the additional staging servers are a static set, but one of >>> the sysadmins is working on setting up an automated EC2 pool of >>> staging servers, which can be deployed as needed to test features or >>> integration. >>> >>> >>> This is working out quite well for us, but it would be quite a bit to >>> set up all at once :) >>> >>> >>> -- justin >>> >>> >>> On Tue, Sep 20, 2011 at 6:34 PM, Wade Preston Shearer >>> <[email protected]> wrote: >>>> I am considering ways to improve our testing, staging, and deployment >>>> processes. We have multiple sites being worked on by multiple developers. >>>> I would like to hear how others (especially large teams) are doing it. >>>> >>>> >>>> Our current process works like this: >>>> >>>> 1. developer writes code, tests, and then commits to trunk >>>> >>>> 2. developer submits a push request to the "push-guy" >>>> >>>> 3. push-guy updates beta server (working copy of trunk) with files in >>>> request and returns note to developer >>>> >>>> 4. developer checks code on beta server and returns note of success >>>> >>>> 5. push-guy rsyncs files to staging server and returns note to developer >>>> >>>> 6. developer checks code on staging server and returns note of success >>>> >>>> 7. push-guy rysncs files to production cluster and returns note to >>>> developer >>>> >>>> 8. developer checks code on production server(s) and returns note of >>>> success >>>> >>>> >>>> This works well for a single developer, but once you have multiple >>>> developers submitting requests, testing, and verifying, it gets really >>>> hard to manage. And, it gets especially difficult when you have certain >>>> files that are found buggy and shouldn't be pushed with the rest of the >>>> updates. >>>> >>>> To help clarify things and provide ways to roll back easier, we have been >>>> considering implementing a beta branch and a stable tag. This would allow >>>> us to be okay with trunk being unstable and only merge over files that >>>> should be deployed. The beta server would be a working copy of the beta >>>> branch and the staging server wold be a working copy of the stable branch. >>>> We would then rsync from staging to the production cluster. >>>> >>>> This doesn't help much with management of things though (submission of >>>> items for deployments, testing, verifying that it's been peer-reviewed, >>>> tested, etc.) and merging adds a lot of extra steps (merge, commit, merge, >>>> commit). >>>> >>>> What are you doing? What systems have you heard of large teams using? >>>> >>>> >>>> >>>> >>>> /* >>>> PLUG: http://plug.org, #utah on irc.freenode.net >>>> Unsubscribe: http://plug.org/mailman/options/plug >>>> Don't fear the penguin. >>>> */ >>>> >>> >>> >>> >>> -- >>> http://justinhileman.com >>> >>> /* >>> PLUG: http://plug.org, #utah on irc.freenode.net >>> Unsubscribe: http://plug.org/mailman/options/plug >>> Don't fear the penguin. >>> */ >> >> /* >> PLUG: http://plug.org, #utah on irc.freenode.net >> Unsubscribe: http://plug.org/mailman/options/plug >> Don't fear the penguin. >> */ > > > /* > PLUG: http://plug.org, #utah on irc.freenode.net > Unsubscribe: http://plug.org/mailman/options/plug > Don't fear the penguin. > */ > -- http://justinhileman.com /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
