Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
By orthoducks on
I just completed a complex group of updates to my client's host, involving about 20 manual steps using a combination of FTP, phpMyAdmin, and a local program editor. I tested everything on my development system first and prepared a written procedure to follow, but nevertheless the process was time-consuming and stressful. Despite the written procedure, I made a couple of mistakes which I had to figure out and correct "on stage."
How do experienced developers and SysAdmins deal with this problem? It seems to me that there must be some way to automate maintenance of production systems, at least in part.
Comments
Automatic is hard on unknown target platforms
[sorry if this double-posts, d.o. is frozen on me for 10 mins]
I also have tried keeping a log of some major installs to see if there was a streamline process, but...
How many of the actions you took were specific to your host/platform/security clearance/admin panel/site and how many were obviously generic?
I ended up with almost 90% being in the first group, and only a couple of steps being basic.
To write a real howto that would apply to more than one hosting provider seems to take more branches, options and ifs and buts than actual deployment steps.
eg - "upload the database to the server"
... Using FTP? SCP? Host File manager? PHPMyAdmin? Remote SQL port?
On any given host, possibly two out of those 5 options may be available.
eg - "create database user"
.. Using PHPMyAdmin? Do you have the rights? Using MySQL shell? Using a host-specific control panel (I've seen dozens, all different)? Raising a ticket?
So although I've written a handful of scripts that DO help me sync up sites individually (and even a full module that does so by RPC), they are more often very tailored short shell scripts with embedded configs and paths. Because adding flexibility and configurations quickly means that there is more unused code than used code.
I can write a one-liner that uses rsync to match up all the modified files from A to B. Another line to take a DB dump, One more to scp it up and another line to rsh unpack it remotely.
4 lines and I've done an entire deploy. BUT only for that site in that case. Adding flexibility for one more case takes 4x4 lines. for another case 4x4x4 .
So I've given up on that, I'll just keep tuning my process by hand and have 4+4+4 lines of code to deploy to my three hosts.
What I'm saying is that writing a good automation script (which must neccessarily include a heap of error-checking and handling that's handled differently when a human is driving) is an exponentially harder job than just doing the thing.
It's the difference between programming a little robot that can manipulate rough ground, cross the road safely, locate and identify a shop, select a good magazine and return to you safely - vs just walking down the road yourself. You'd think there is an easier way, but actually doing it is hard when you realize the extra context information needed to automate it.
That SAID, there are a few admin utils like IIRC deploy.module that can help with certain steps you may want to try. I've found that understanding them and evaluating whether those methods can fit into my workflow is as hard as just doing it myself anyway... YMMV
.dan.
How to troubleshoot Drupal | http://www.coders.co.nz/
.dan. is the New Zealand Drupal Developer working on Government Web Standards
Different parts of the elephant?
I think we're approaching different parts of the elephant. I may be at fault for making an unsupported assumption that best practices for deployment would involve scripting, and again for saying so in a way that could be interpreted to mean shell scripting. As it happens, my current client's host does not allow shell access at all. I was thinking of scripting in a more general sense: what tools are available to automate the deployment process, and how are they best used?
Stepping back farther, I would restate my question like this: what can I learn from people who have much more experience than I at deploying server-based applications?
I'll take a look at deploy.module and see what it can do for me.
That said, due to my inexperience, perhaps, I am more optimistic than you are about the possibility of scripting deployment operations. Your observation about the resource differences from site to site are quite valid, and they introduce an element of difficulty that is not found in most programming environments. Nevertheless, I think that problem could be overcome sufficiently to produce a useful tool, and I hope that someone will do so, if they have not done so already.
Sorry if my opinion comes
Sorry if my opinion comes off as a bit negative :-} There may be solutions I haven't seen or thought of.
anyway, if there is anything that could be extended off of this handbook on migration procedures that would be cool. Please add any gotchas you encountered there, and possibly an evaluation of the assorted admin tools if you find one that works.
.dan.
How to troubleshoot Drupal | http://www.coders.co.nz/
.dan. is the New Zealand Drupal Developer working on Government Web Standards
I'll take a look
Thanks; I'll take a look at the handbook and comment if it seems appropriate.
BTW, I couldn't find a "deploy" module. There is a "Deployment" module, but according to the abstract it only manages data. So far my server maintenance work has been: files and directories 100%, data zero. I may find uses for the module after I develop more experience, but if I had had it in hand when I started mucking around with servers, I wouldn't have had a chance to try it yet.