Hi Lee, In the longer term I'm aiming to use something along the lines of what you've mentioned (see below for 1.x) but there's a couple of scenarios:
Targeted deployment Ideally your environment matches that to which you'll be deploying to. If you control the server infrastructure then this is less of a problem - you'll build the server yourself (ideally via an automated deployment process) and building a VM from this is trivial. If you don't however control the server infrastructure then you have a more complex situation to deal with. If the gods are smiling then they've built their server completely from public distros and repos and used a package manager for all installs. If this is the case you can dump the package list and server build - and rebase an image yourself. Often however they have a custom OS build (tweaked for whatever reason), local repositories (hopefully mirrored) but sometimes not and a few extras thrown in. This makes building an image that represents the environment you're going to use, while not impossible, generally non-trivial. ServerGrove(http://www.servergrove.com/), forward-thinking & proactive, are interested in providing an image to their customers that does just this - allows people to develop locally in an environment that represents where the application will be deployed. A growing trend with hosting providers is where they allow you to upload your own image to the hosting environment allowing you to build your own OS (subject of course to licensing requirements). One of the aims of the VM was to provide a way for devs to start locally and then upload a copy of the image to the hosting environment. With a few caveats (mostly around networking) you're assured of 100% success for the deployed project as you've been able to put it through its paces in before uploading. Non-Targeted Deployment In this scenario the developer is building applications for non-specified specified servers - either because they don't have or haven't selected the hosting environment yet, they don't have complete information from the project sponsor - or some other reason (it's weird and wacky out there). Another possible deployment is Open Source projects where the deployed application may be any OS - and yet you'd like to have a common "known" environment for developers and end-users. In this situation the VM helps both the developer and the project sponsor - as it'll allow the dev to share the VM with the sponsor for testing and signoff. Essentially passing the monkey wrt the hosting environment. Under this category falls the what-if and migration. General Approach (now and 1.x) The current approach I've taken is mainly aimed at providing a lean-learning curve, a clean & repeatable environment to the community developing against Symfony and the Zend Framework (the Zend side is mostly a freebie but also aimed at helping people with Lucene search issues). With each build I test to ensure that all sf frameworks work by deploying a test application that covers ORM's, plugins, routing and the DB/httpd. With the build I try to ensure that it's portable and therefore works against the major VM Client vendors (VirtualBox, VMWare and Xen currently). The aim of the 1.0 release is to have something built and packaged ready to run - much like the sf sandbox currently works. While VM's have been around for a while - and while installing linux has become more user friendly - there's still a lot of areas you can trip-up building images and installing OS's. One of the aims was to remove this as a blocker to devs wanting to just get down to developing applications. With the release of 1.0 there should be the following images and deployments available: * Images o devSFCoreServer o devSFCoreIDE * Deployments o Stand alone (everything in one box for simple dev projects) o Load Balanced (built using devSFCore with configuration that puts the server into modes: lb [load balanced], web [web server, memcached & no db], db [db, svn, no httpd but a http management interface]) * Project helpers o Helpers to aid start-up of projects and development. Things like building the root development folder, linking to the version of the framework you wish to use, creating and configuring the DB, configuring the application to use the DB and running tests on the initial setup. Think a2ensite for creating a symfony application and you'll get the picture. The intention isn't so much to dumb down - but to streamline and to facilitate adoption by those not that familiar with symfony. Included will be log creation of the actual steps involved to help devs understand what to do. With Deployments the general idea is that you'll be able to run multiple images in modes - to facilitate testing, architecture scenarios, etc. With this you run one image as a DB, several as web servers and drop in a load balancer - and hey-presto you have a way to test how your application performs when scaling out. With the 1.x branch I'm intending to go with a much lighter approach - still with some base images for various distributions and deployments (there will be standard and live images along the same approach as the live-cd used with some distributions) but using some of the approaches you've outlined for providing the packages and for linking in with repositories. This approach however requires some infrastructure to support it - and infrastructure = time + resources and resources = money. This approach essentially extends the current sf sandbox to a deployed image mode. It'll work out compatibilities, issues and fixes, deal with things like pear and pecl dependencies, PDO and handle the deployments you'll see above. With 1.x comes features for both devs and hosters (and allows for Targeted deployment). Hosters can build their base image and include the needed components into the image - and share it with their customers(the devs). Devs can download and use the image - and it'll pull all the needed parts down. When they are ready to deploy - then from within the VM they can provision and deploy the application. With the provisioning on the hosting provider side building the image locally, deploying it and then accepting the deployment of the application. Should the dev decide to move hosting providers to another supporting this model - as it'll be built using the same components (but probably a different base OS) - then it should be a simple process to download their base image, deploy from the current VM to the new VM, test and redeploy. That kinda went on a bit but that's my current thinking :-) Thanks for the feedback -----Original Message----- From: symfony-users@googlegroups.com [mailto:symfony-us...@googlegroups.com] On Behalf Of Lee Bolding Sent: 21 May 2009 14:40 To: symfony-users@googlegroups.com Subject: [symfony-users] Re: Symfony Virtual Machine Good work David! However, I'd recommend that if you intend to use a VM for development (I already do), that you build it yourself, so that it mirrors the exact configuration of your deployment environment. Unless you do that, using a VM provides very little benefit, as you still can't be sure that your application will behave exactly the same in your production environment. What I do right now is have the same VM for all of our developers - when a new developer arrives they grab the image file from our server, and check out all of the necessary stuff from our repository (including things like PEAR). We have almost everything in SVN, which allows developers to easily make huge changes to their own VM, and if it is to be propagated to the live server, it's then checked into SVN, so that we can check out the changes from SVN directly onto the live server. A good example of this would be upgrading Symfony via PEAR. We do it on a developer VM, test, and if it works, we then commit the changed /usr/share/php/PEAR to SVN and from the live server(s) perform an "svn up" in the same directory. Instant, no hassle update :) Every other developer then does the same - performs an "svn up" in their /usr/share/php/PEAR directory, so that everybody then has the same version of Symfony as the production environment. At some point I'll resurrect my blog and make a blog post about how/ why to set up an effective development VM. I've just created a new one using Fedora 9 after we upgraded our servers, and put Fedora 9 on them instead of the previous Debian. On 20 May 2009, at 13:54, David Ashwood wrote: > Wotcha Guys and Gals, > > I've just launched a site which allows you to download a Virtual > Machine setup and ready to run against Symfony and Zend. > It's based on Ubuntu Server x86, comes with the latest versions of > Apache, MySQL, subversion, PHP & Zend - and includes Symfony 1.0, > 1.1, 1.2 and 1.3 (via svn so it's a snitch to refresh). > It has the current versions of Pear & Pecl - so installing plugins > shouldn't be a problem. It comes with the Zend Server (community > edition) integrated - so you can remotely manage your environment > via a web browser. > > It's deployed via OVF - so just download, extract and import into > your favourite Virtual Machine Client - otherwise I'd suggest > installing the VirtualBox Client (http://www.virtualbox.org/) which > works under Windows and *nix. > > The VM Images and complete info can be found at: http://sipx.ws and > the Issues tracking is at http://project.inspiredthinking.co.uk/projects/show/symfony-vm > > With this type of approach you can develop and test against an > environment in a repeatable fashion. By using the snapshot/rollback > features found in many VM Clients - you can roll back an environment > quickly and easily - allowing you to see deploy/test changes outside > of your production environment. > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~----------~----~----~----~------~----~------~--~---
