Thanks for all your feedback everyone. It gives me a bit of guideance as I try to dig up more. I'd only class myself as an SVN "user" so it appears this may be the first area I should be looking into more if I want to get my head around how it interacts with the different environments.
Cheers Aaron ----- Original Message ----- From: "Robin" <[email protected]> To: <[email protected]> Sent: Wednesday, July 22, 2009 2:28 PM Subject: [phpug] Re: Environment setup, source control and Deployment procedures We have a development server and a production server. On the production server we have svn, cruisecontrol, phpundercontrol. When commits are made cruisecontrol runs a build using php documentor, php codesniffer and phpunit, if any of the test fail the commit fails if they pass the commit is finished and then a post commit runs to add the diffs to a "staging" directory that we can test manually before moving it to our production server. This is a great tutorial on how to set up the above http://blueparabola.com/blog/installing-phpundercontrol-debian-etch Robin -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Dan Khan Sent: 22 July 2009 13:17 To: [email protected] Subject: [phpug] Re: Environment setup, source control and Deployment procedures +1 Dalibor. We have a similar setup. Dev - LAMP stack Vista - local branch development Testing - LAMP stack Debian - cutting edge SVN trunk, auto updated from repo regularly/each commit Staging - LAMP stack Debian - deployment test servers running against real anonymised production data/same hardware spec Production - externally hosted debian servers Dev is local developer PCs Testing and Staging are VMs on a single quad-core 12GB RAM internal server running VMware ESXi. Stagin envinroment has duplicate hardware and software configuration/versions as production versions. Production is hosted externally by a variety of providers We also run a number of internal (virtual) linux servers to manage SVN server, internal DNS, UPS, dev/ops wiki, release management, CMS, backup, scratch servers, etc. We use SVN in house for all source code/ops scripts - moved inhouse from offshore hosting for a massive speed increase - from 2Kb/s to 3Mb/s - merge in 5 seconds :) We have a local backup NAS server for internal and production servers - will migrate scripts to AWS S3 over time. Custom rolled PHP deployment scripts from our internal release server to staging and production (auto export SVN->Local->prep->SSH/Rsync->Semi-full automated live rollout) On my list to investigate phpUnderControl, SystemImager, Puppet, Chef, and a number of other automated deployment and system management tools. HTH Cheers, -Dan On Wed, Jul 22, 2009 at 10:40 AM, Dalibor Andzakovic<[email protected]> wrote: > Re Environments: > > > > We tend to run 4 environments, development, testing, staging and finally > production. It is a good idea to run the environments as separate as > possible. > > > > Development is generally the dev’s own machine. Anything goes here. Testing > and staging we tend to run on a separate VMs and production is preferably > run on its own hardware or at least in a separate resource pool on your > favourite virtualization platform. Reason for having separate testing and > staging is this: Testers will do dev testing in the test environment which > will have different software builds/versions of the underlying stack. > Staging environment is kept as a copy of the production (in terms of > software) in order to pickup any pesky deployment issues. In other words we > deploy twice to try and avoid last minute deployment hair pulling. > > > > Re Release Management: > > > > Code releases are all done from a central repository. CVS/Subversion work OK > for this, but I’m a fan of mercurial these days. It’s easy enough to > designate a Mercurial repo as a central point that all the devs push > changesets to. There are several options on the release front depending if > your target is a package, installer or simply a website update. For simple > site updates I tend to just pull from the code repository branch. I have > also built distribution packages but that only becomes worthwhile if you > need to update a number of hosts. Good starting point for the release > management can be found at > http//www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/index.html > > > > HTH > > > > dali > > > > From: [email protected] [mailto:[email protected]] On Behalf > Of Aaron Cooper > Sent: Wednesday, 22 July 2009 10:06 a.m. > To: [email protected] > Subject: [phpug] Environment setup, source control and Deployment procedures > > > > I know this topic depends alot on the organization, but I am looking into > Development/Staging/Production enviroments, how they interact with source > control (SVN) and Deployment procedures from Staging to Production in a bid > to build a case study for my employer. > > > > While I totally understand the environment side of things, just how source > control fits in to each environment, and deployment procedures are a bit > grey for me. I'm also a bit grey on how each environment should be setup in > terms of hardware. Obviously Production should be on it's own, but is having > Development and Staging on one box a terrible idea? What I am looking for is > examples of systems from Development to Production. > > > > I was wondering if you lot know of some good literature or online resources > on this topic (with examples). PHP specific examples aren't nessecary, but a > Web Development focus would be handy obviously. > > > > Cheers > > Aaron > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ NZ PHP Users Group: http://groups.google.com/group/nzphpug To post, send email to [email protected] To unsubscribe, send email to [email protected] -~----------~----~----~----~------~----~------~--~---
