The target here is to backup & update (core, db and plugins) a Wordpress farm, i mean, a bunch of different Wps over several servers.
In case your servers run PHP v5.3+ you may know wp-cli, if not, go try! wp-cli allows you to run different Wp tasks on command-line, so great point to automate.
My tool of choice to manage servers is Ansible, an infrastructure automation tool, simple and to the point.
We want to set the servers and paths, and path to the backups. We want to have one in case any update breaks something. Also we may need a name for the backup files.
So we need to associate a name and a path to each Wp host.
In order to accomplish such a structured data per host on Ansible I didn’t find any proper way, as the inventory file doesn’t to support this. I opened a Feature request for that.
After trying several dict approaches, my solution, was to associate the host on a list (I couldn’t make a dict to work), through a var-name relation such as:
1 2 3 4 5 6 7 8 9 10 |
|
You can test this with the debug command:
1 2 |
|
Now the data per host is set and we can target as follows:
1 2 3 |
|
This lacks a nice informative timestamp.
Again Ansible doesn’t provide a standarized way of timestamp. There is another Feature Request, closed, but it is recently taking relevance.
So I managed to get it from a register:
1 2 |
|
Now we can make a proper log name such as:
1
|
|
I made a playbook to install wp-cli, backup Wp files & db, and update Wp core, db & plugins.
You can take a look to the final role available at Github.
First make a small task manually, then automate it. Second add complex manually, then:
]]>Automate all the things!
Let’s get dirty!
If you didn’t previously:
1 2 |
|
1 2 |
|
At this point you can generate a package.json
through Satis in order to use a local repository.
To generate a Composer-repo from a Git-repo the only requirement is to have a valid composer.json
on the root folder at master branch.
Composer helps you to do this:
1
|
|
All you need is to edit a satis.json
file
1 2 3 4 5 6 7 8 9 10 11 12 |
|
And generate the Composer repo:
1
|
|
And you are done!!!
Edit your composer.json
, add your require package name and the local repo, which you can publish through http in order to be accesed locally:
1 2 3 4 |
|
You can avoid coping the repositories line by adding the repository to the default reposiitories:
1 2 3 4 5 6 7 8 |
|
This is quite complex just to get a private Composer repo, so next post in this serie will cover how to automate this tasks, and get a local GitHub working.
]]>How can we improve our code quality while keeping the productivity?
Code-Reuse
Since its 5.3 version PHP has become a more popular due to a bunch of rich features. Namespaces landed on PHP and one of the bests improvements since that has been Composer.
Most of us (PHP devs) use Composer to get libraries packed on our projects avoiding dependency troubleshooting. But why not using it locally?
We can get a reuse environment on your team/office avoiding duplicated code and becoming people more productive. Assuming people will code components many other benefits will apply:
If you don’t mind how to get this work, next post will cover how to create and use local packages using Satis to generate a local composer reposotory throught local Git repositories.
You can even improve the result adding a private GitHub flavored interface GitList
]]>