Note that there are some explanatory texts on larger screens.

plurals
  1. POSVN Web Development Workflow
    text
    copied!<p>I've read through many of the questions here on SO relating to this issue, but I can't really find any good advice that fits our situation. I inherited this work flow, and I'm trying to make it better.</p> <p><strong>Our setup</strong></p> <ul> <li>PHP code base (Kohana in particular)</li> <li>code base powers ~60 sites, each with unique templates (i.e. 60 QA [Quality Assurance] domains too)</li> <li>each site has A-records for different assets and resources (i.e. 8 A-records for each domain)</li> <li>3 developers</li> <li>3 designers</li> <li>developers have VMware image of production server for local development</li> <li>designers do not</li> <li>shared physical development server used for QA, a post-commit update keeps this server at the current HEAD of trunk at all times</li> <li>production server, updated to a mix and match of different revisions depending on what features are live</li> </ul> <p><strong>Our Work flow</strong></p> <ul> <li>Developers work locally until a given feature is complete and then commit the whole feature to trunk for internal QA.</li> <li>Designers make small changes to CSS/images/templates only. They commit directly to trunk, QA their own changes, and update the corresponding files on the production server, generally speaking, immediately after their QA.</li> <li>When features are ready to go live, the production server is manually updated to the proper revision numbers for each file related to the feature. Sometimes this is simple, other times it's quite hairy (lots of <code>svn log</code> calls to look for upstream dependencies). </li> </ul> <p><strong>Our problems</strong></p> <ul> <li>With three different developers working on different features that need different amounts of QA, we find ourselves running into upstream dependency issues on a regular basis.</li> <li>At any given time, we don't have a way to programatically determine which features are on the production server and which are not. <code>svn status -u</code> will show us which files are not up to date, but that's generally not a clear picture of features.</li> </ul> <p><strong>What I know</strong></p> <ul> <li>Some of our problems could be alleviated by having a production branch. We could at least monitor which features were being added into production and when, although this wouldn't solve upstream dependency issues.</li> <li>Feature branches are an option, and we have tried that in the past. Due to the fact that our software requires 60 QA domains per branch, we run into process management issues there. For instance, the creation of 480 (60 domains x 8 records per domain) A-records for each feature branch.</li> <li>Developer branches are also an option, but our feature QA times vary. I can't definitely say that a previous feature will be out of QA before I need to commit something else.</li> </ul> <p><strong>Upstream Dependency Example</strong></p> <ul> <li>Developer A adds a new slideshow feature in both the admin and front-end.</li> <li>Developer B adds a new feedback feature in both the admin and front-end.</li> <li>Both of these features are intertwined with the Location model/controller logic, so changes are made to those associated files to account for both of the new features.</li> <li>The slideshow feature enters QA, but is held up by some developmental oversight or scope creep.</li> <li>The feedback feature enters QA and passes without issue.</li> <li>We want to follow the timeline and push the feedback feature to production, but we cannot do it directly because both features required changes to the Location model/controller. That is, we can't just do an <code>svn update file1 file2 file3</code>.</li> <li><strong>Note:</strong> <em>This is a simple example, and it can be worked around by doing some reverse merging. Oftentimes our problems are complex than this.</em></li> </ul> <p><strong>Multi-site Structure Information</strong></p> <ul> <li>We have a number of pre-defined structural themes, consisting of views, images, CSS files, JS files, etc.</li> <li>Each site is assigned a theme.</li> <li>For branding and expandability reasons, each site can override a theme view with a custom view or include additional site-specific CSS/JS files.</li> </ul> <p>I'm sure there are some other people out there that have struggled with similar issues, and I'm hoping to get some insight from you smart people on the Internet. Please feel free to ask questions if something I said seems clear as mud!</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload