Working on LaSalleMart’s first live site with Zach Atkinson highlighted a problem with Akeeba Live Update.
Live Update is a subset of the Akeeba Release System. LU allows you to update LaSalleMart from your Joomla Administrator, instead of trudging to my download site, logging in, downloading, etc etc.
It really works. There’s an icon in the LaSalleMart dashboard that tells you if you have the latest version. If not, you click to the update page.
On my end of things, every time I have an update, I have to go to my ARS admin and fill out forms. Which is fine if I have one new release every week or two. But, what happens when I have a new release daily? Or even — gasp! — more than one per day? Then, it’s a major PITA to update the ARS admin.
A new release per day? You betcha! If I make one small change — which I did late this afternoon — why wait to release it? Philosophically, I want all LaSalleMart sites to have my changes asap. Continuous Integration, Continuous Deployment — the key word is “continuous”!
GitHub.com is great. We update the repo(s), and the code is ready for Phing.
Phing is proving to be so powerful that I’m starting to consider it a weapon. Once the LaSalleMart repositories are PUSHed, it takes mere minutes to get all three LaSalleMart flavours uploaded to the Akeeba Release System folders.
However, updating my ARS admin is proving to be a bottleneck. In fact, knowing I have to update it has caused me to delay running my Phing builds. This is a Very Bad Behaviour: the antithesis of “continuous”.
The Joomla installer a bottleneck. Not just physically; but, it is a nasty limiting mindset. I have Grand Plans to bypass the Joomla installer completely. However, in the here-and-now, we are using the Joomla installer; and, using ARS.
So, after achieving “continuous” with GitHub and Phing, how to I overcome the ARS bottleneck? Well, did I mention that Phing is very powerful?
Phing does databases. Phing can talk to the ARS database directly. The Phing task is called “pdosqlexec”
So, Phing UPDATEs the ARS database directly. Look Ma, no Administrator! Bada Bing, Phing uploads the new ZIP files, and then does the UPDATEs right after.
But, I cheated. As Nicholas will probably read this, I better fess up! Phing UPDATEs #__ars_releases only. I don’t bother adding brand new releases, I just pretend that my latest ZIPs are the very first releases. Saves a lot of bother this way, although not what ARS intends. Well, I use ARS as a conduit between code origination and final upstream code, rather than a software release mechanism. It’s continuous deployment, baby!
I ended up tweaking manifest.xml and defines.php (and a few other things). Most fun reserved for phiguring out Phing. A journey learning how-to set up the automation. But, whooooooaaaa, now that I have the automation in place, it sings!
LaSalleMart updates can be on your site within 10 minutes of the GitHub update. With the automation, I have no extra steps with the Phing builds, except to update the separate parameter file (which is now a single point of entry instead of 3 separate files).
Forget about waiting for releases. I do ‘em as I go along. Continuously.
Even via good ol’ Live Update, we deploy continuously!
This is the modern way of doing it. Phing & GitHub are powerful ways to make it happen for us.
UPDATE (June 26, 2012):
From Nicholas:
The BleedingEdge category type was designed to remedy this issue. Just create a new directory with the version number and upload the files in it. Coupled with the Automatic Descriptions feature it’s upload and publish with zero clicks. I have a Phing task called ftpdeploy in all my components. Issuing a new dev release is as simple as “phing ftpdeploy” for me
Feel free to browse my Git repos and salvage all the Phing code you need
[https://akeeba.assembla.
com/code/akeeba-release- system/subversion/nodes ]
Nicholas, awesome! I will take a look at this Thank you!
