2010/3/30 Tomáš Znamenáček <tomas.znamena...@gmail.com> > > I have a Catalyst application that I would like to upload from the > development box to the production server. Is there some kind of best > practice to do that? My requirements: >
I don't think there's any standard approach. I know many people seem to just do a checkout from the repository. > 1) The process should take care of the dependencies and run the tests > before installing. (Let’s say the deps are declared in Makefile.PL > or Build.PL.) > I have a separate cron job that polls the repository looking for changes. When it notices that a new version has been checked in it checks it out and runs the full test suite. A big fat email goes out if test do not pass. If it passes, but a previous run failed an email also goes back congratulating everyone on fixing the problem. This works well because the same process can be used on multiple applications and is constantly running -- not just when it's crunch time to push a release. > 2) It would be nice to keep the application isolated in one directory > so that I can keep several instances under the same account to do > primitive staging. > Agreed. I have a separate build process. This is a simple process and doesn't run any tests (because the build process may happen on a "build server" w/o dependencies needed by the application). This simply does an svn export, then it runs build/build_app.sh which then runs whatever scripts are needed to build that specific application. For example, minify and combine css and javascript, etc. Then a tarball is built of this export (named after the application and version) and made available on a web server. This can then be "pushed" to any server. The push process simply fetches the tarball from the build web server, unpacks it into it's version-specific directory and runs the Makefile to test for dependencies on the target machine. If that passes a symlink is updated to point to this new version and the web server is restarted. The symlink makes it easy to revert to a previous version or to have multiple versions on the same machine for testing. The applications have separate YAML files for different environments. There might be "dev.yml", "testing.yml", "qa.yml", and "produciton.yml". Each machine has a file in /etc/<$app_name> that sets what environment the application should start in (i.e. what YAML config file to use). Push to testing and the app starts and uses the testing database as configured in testing.yml. I've used this method for pushing directly to production, but in other cases use it for staging and then rsync to production servers from staging. > I’ve read something about local::lib, but I’m still not sure about how > to put things together. This has to be a common scenario, isn’t it? When > you are finished updating the development version, what do you call to > upload the update to the production server and what exactly happens > along the way? > Good question. Hopefully someone has a great solution. In the past I've used cfengine to make sure machines have the right dependencies. I've also used a local lib and rsynced that and messed with @INC and PERL5LIB, which doesn't make me happy. (Think about init.d scripts, cron jobs, etc.) The next approach is to build packages (deb or rpm) of the application and dependencies and let the OS package manager handle it all. The goal there, besides making it easy for deployment, is to break out common code shared by apps into libraries. That said, there is something to be said with throwing everything in the application's lib directory since you know when it's pushed you will have exactly the same code used in development. Lot easier to revert when everything is under a a single symlink. I've heard of people that build an entire Perl installation and keep that separate from the OS installed Perl. -- Bill Moseley mose...@hank.org
_______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
