Elgg Deployment Strategies

How do you deploy Elgg on your servers?

I still have not moved to Git, so I still rely on Subversion.

Currently the repo has the full Elgg code base than just the mods that have been modified. svn:ignore has been set on settings.php since it contains host-based connection settings so that I can seamlessly use the same code on the development, staging and production set ups.

The SVN copy on the development set up has a virtual host mapped to it allowing me to test changes instantly. Both staging and production have full SVN working copies checked out on them. New changes are deployed with a 'svn update' on these followed by a 'svn export' into the vhost doc root.

  • i imagine you have a pretty complete methodology there.. :)

    i'm just getting started in configuring my server and development environment..

    i'm installing subversion now for the first time (i've only used MS sourcesafe before as an equivalent so know how these apps basically work but not the details of svn and git etc).

    so can git access the subversion repository just as well as a subversion client?

    is there any particular benefit of git over subversion? from your words it seems you see the benefit as obvious..

    i've searched the community here and haven't found a huge amount on the subject..

     

    what i'd like to be able to do is maintain a local version of elgg with my own customisations and then easily manage integration of updates when they are are released by the elgg core team.

    i'll play with it all soon myself, but just wondered if you or anyone had any tips in advance?

    thanks for sharing :)

  • Git can access the SVN repo: http://www.kernel.org/pub/software/scm/git/docs/git-svn.html But I would recommend that you stick to Git if you don't have legacy issues.

     

    http://stackoverflow.com/questions/279169/deploy-php-using-git is a decent depolyment strategy using Git, but I would prefer something like a 'svn export' than a full repo to be in the a publicly accessible directory.

     

    Git is a lot faster, leaner and has a lot of momentum behind it. Also, most importantly, branching is easier, which is a bit of a pain with SVN and the merges that follow.

     

    I do already do a lot of what you say you want to do.

     

    My process works like this:

     

    hack code in the development env (my laptop)

    svn commit the changes to the SVN repo (on a different machine from the production set up)

    log into the production server, do a svn update on the local svn checkout there, export it to the web server directories. 

    If you have a tabbed software like the terminal on OS X, it all gets done in less than 5 minutes.

    I could make it a lot better by writing a shell script, but I am being a bit lazy there.