Advise Requested: Branching, Merging, and Deployment

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

Time is valuable, so any of it is appreciated.  I'm looking for sound advice on a good strategy for maximizing git's branching and merging capabilities to assist us in frequent web-app deployments.

--
I am running a project (in git) that has ~20,000 source files and several full-time developers making changes constantly.  The project is a web-app, so the files are a mix of textual source code and (usually) small binary files.

We were using Subversion for some time, but eventually the deficiencies (like "svn status == 90 seconds" and no merge tracking) caused me to look for a better solution.  After a lot of research, I ended up here, and we are in the process of moving all of our projects to git.  Thanks, by the way!

We have always maintained three copies of each project - [Development, Preview, Production].  Changes were typically made in Development sites and tested.  Then (manually) copied to the Preview sites and tested.  Finally, they would be manually copied to the Production site.

It becomes very difficult to tell (manually) who changed what line of what file for each task that needs to be moved into Production.  Some tasks are long-running, some are short, but in general, it's a mess.

This is quite different from traditional software development where releases are done on a more "predictable" basis.  Unfortunately in our case, releases are done on a sub-daily basis (yes, I'm working on that).  We need a lot of agility in whatever strategy we choose.

--
Here are some requirements:
- Separate change-sets.  Keep track of the changes introduced by each task separately.
- Have changeset ABC stay in the Preview level for a variable amount of time.
- Create, Preview, and move to Production changeset DEF while changeset ABC sits in the Preview level.
- Developer sanity :)

Here are some intents:
- To maintain a branch called "Production" which represents what is in production
- To maintain a branch called "Preview" which represents what is being previewed


Any help is greatly appreciated.

--
Best Regards,
 
Jason Garber
Senior Systems Engineer
IonZoft, Inc.
 
(814) 941-2390
jgarber@xxxxxxxxxxx
 
 


-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux