Peter,
I think you missed a step in the process I outlined... you never touch
master unless you are deploying to production, so there's never a reason to
freeze anything.
A typical workflow would be like this:
* branch off master (the code you know is on production), make new features
or bugfixes, repeat many times with many branches
* checkout staging
* hard-reset to the first branch you want to stage
* merge all other branches to stage
* push, may require a --force, but probably won't
* deploy to staging server from staging branch
* test on staging... everything is good to deploy to production
* checkout master
* merge staging, this should always do a fast-forward merge unless you've
been working in master... which would be bad because those changes were not
deployed to staging to test.
* create a tag!
* push master and tag
* deploy to production from master
* GOTO 10
The reason I like this method is that it helps other developers know what's
on the servers. There's no need to ask what was last deployed, you know
that staging is on the staging server and master is on the production
server. Tags help you find previous production deploys. Staging deploy
history doesn't really matter, only the current deploy, so you only need the
branch for that. Also, by never working directly in master, you avoid
issues of people "stepping on each other's toes". Everyone-in-trunk is best
left for svn, where it's anywhere from a minor pain to a huge headache to
branch.
If a staged deploy is bad, you can reset back, re-merge, and re-deploy until
you're happy. after it's deployed to production, you see at a glance what
branches aren't merged into master, and fix them up.
The key to the whole workflow is that "master" is what is live on the
server. Everything after that is in a topic branch until it is merged into
master and deployed. You never leave undeployed commits in master.
Tekkub
Github Tech Support
http://support.github.com/
Join us on IRC: #github on freenode.net
Discussion group: [email protected]
On Tue, Jul 21, 2009 at 11:45 PM, Icebreaker <[email protected]>wrote:
> I think that the best way to go is to have a staging server which contains
> the most up to date version of the master branch. (updated automatically
> every 15 minutes or less).
>
> No fixes should be deployed to the release server between iterations,
> except critical ones (deploying only the involved files).
>
> At the end of an iteration, the master branch can be deployed as-is to the
> release server.
>
> Imho having (and keeping up to date) too many branches just causes
> confusion and it can be time consuming dealing with all the possible
> conflicts, etc that may appear.
>
> Just my 2 cents :)
>
> On Wed, Jul 22, 2009 at 8:16 AM, Peter Shenkin <[email protected]> wrote:
>
>>
>> On Wed, Jul 22, 2009 at 12:46 AM, Tekkub<[email protected]> wrote:
>> > Staging would be the server you deploy to to test things... somewhere in
>> the
>> > middle between development and production.
>>
>> Thanks....
>>
>> But then why wouldn't you deploy from the staging branch? If you plan
>> to deploy from the master, wouldn't you have to freeze merges into the
>> master while the testing is going on?
>>
>> Once you have feature freeze, it seems more logical to define a branch
>> to use for testing, bug fixing, and release (deployment), freeing up
>> the master for the merging of projects to be released later.
>>
>> -P.
>>
>>
>>
>
>
> --
>
>
> Joan Crawford<http://www.brainyquote.com/quotes/authors/j/joan_crawford.html>
> - "I, Joan Crawford, I believe in the dollar. Everything I earn, I spend."
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"GitHub" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/github?hl=en
-~----------~----~----~----~------~----~------~--~---
