On Thu, Jul 24, 2014 at 4:25 PM, David Cantrell <da...@cantrell.org.uk> wrote:
> Our "deployment process" at work isn't so much a well-documented > dependable repeatable process as a modern dance interpretation of > lemonparty. It needs taking out and shooting. > > ... > > I'm looking for tools that will make it easy to go from a bunch of code > in a release branch on github to an updated bunch of servers, with > minimal downtime. If it matters we're using Debian. > At $previous, we deployed (mainly bespoke) Catalyst apps using the following toolchain at a small shop: - Gitolite to manage security for repos. - Git Flow to manage workflow in git, with a master, devel (staging) branch. - Mini-cpan repos, which existed in git and were mirrored on multiple servers. - The devel servers were basically identical to live servers - Apps were installed in /opt/$name as self-contained installations (with the exception of a shared Perl, but we had the ability to install an alternative Perl there). The installations were git repos with tags for each release, so we could roll back if needed. Each instance of an app ran under a under a unique username. The idea was to build on devel (staging) servers, using Carton, and push new versions to the repo. In reality, we never quite got there. We'd build the app in the user's $HOME/src module (which was the source git repo) and just installed the new version into the live servers and updated git accordingly. - Configuration lived in /etc/opt/$name, and was managed by custom Puppet modules. These also contained symlinked web server configs for sites. (If I knew what I know now, I'd have used a common configuration for the webserver and managed the differences in Plack::Middleware, alas.) Each app has a custom Puppet module that uses a base one but set up databases and installed cron jobs as needed. - Database versioning was handled using DBIC::Migration, which worked well for vanilla Postgres. It was (maybe still is) buggy for PostGIS, so we ended up manually updating the SQL for deployment, upgrades and downgrades in git and just used it for deploying upgrades/downgrades. Database upgrades were multi-step: 1. Add new columns/tables/etc to database with schema that used them; 2. Release code that uses new columns, tables etc.; 3. Release code that no longer used; 4. Update database to delete things no longer used; Generally this worked out ok. We did most of the steps manually (it was a small shop with a few apps), but had helper shell scripts to do this. In theory it could have been automated completely, but we never felt the need.
