Alex Moreno

A Drupal Developer in London

Acquia BLT short Drupal8 howto

Working with vm’s makes everything simpler and easier. Easy to reproduce bugs, easy to reproduce features between environments and, most importantly, between developers.

In the past I’ve been working with different solutions, custom mainly, based on puppet, ansible…. Until I arrived to Acquia. Local environments as it happens is a recurrent topic on every team, a clear pattern… and when there is a pattern, you can write something to save some time to those lazy developers ;-). Enter BLT (Pronounced BOLT).
BLT is basically an environment that has everything ready for fast developer on-boarding, easy deployment on different environments (dev, staging, prod, … and of course, local), but also for quick automation of repetitive tasks, like rebuilding your sites, pulling databases...
Configuring BLT is very straightforward, but it will take some reading from you. Keep reading for a TL;DR version:
First, install the requirements:
In Mac it is very easy to do it simply following the brew requirements.
brew tap caskroom/cask

brew install php56 git composer ansible drush

brew cask install virtualbox vagrant
Once this is installed you have blt in your command line:
  blt --version
That’s it, you are ready.
Note: for other operating systems please visit:
Once we have all the tools installed in our computer we can start building apps. It couldn’t be simpler:
    composer create-project --no-interaction acquia/blt-project MY_PROJECT
That will create a base directory from which you can start building your Drupal app. First thing I’d do is moving this to your git repo, i.e. GitHub:
  $ git add .

  $ git commit -m "BLT-00 first commit."

  $ git remote add origin

  $ git push -u origin master
Now, let’s move inside the repo and start doing the magic. Let’s initialise the vm (I am assuming here that we’ll be working on a virtual machine):
  blt vm
It will ask if you want to install Drupalvm, to which we’ll say yes, and afterwards if we want to boot it. Yes again.
At the end of the process you should see a green message like this one:
"Drupal VM booted successfully. Please use vagrant commands to interact with your VM from now on.”
Your vm is ready. Last stop, install a site:
  blt setup
This will install a default Drupal 8 site in docroot. You could put your custom site here, or for example install lighting ( instead of the default one. The best practice for that road would be using composer, although I’ll leave this for a different post.
Now, next step you need is to actually connect your new vm to your Acquia Cloud (AC) environments. You have to do this drush level and BLT level, drush to be able to execute drush against the environments, BLT to be able to sync the databases, build artifacts, etc…
First bit, BLT settings. Edit:
And add in remotes the url to AC. You’ll find this url in AC. Go to, select your application and, in the list of environments, you’ll see on top right an icon called “Application Information”. Click and the first url is what you need. IE:
Your yml file will look like this:

  default_branch: master


   - ''
Lastly, your drush settings. Go to your AC profile page:
Select Credentials and, after confirming your password, you should see 'Drush integration’ in the new page. Download and place the hidden files in your $HOME.
Time to deploy your stuff to Acquia Cloud (or theoretically any other host provider). First thing, you’ll need to add your ssh keys to Acquia Cloud, just:
If you don't have any ssh keys yet there are some good short tutorials out there, it shouldn't take you more than 10 minutes to generate a new ones.
Ready to go, do:
blt deploy -Ddeploy.commitMsg='BLT-000: Deployment test' -Ddeploy.branch='master-build'
Answer ‘y’ to create a tag, return for the default commit message, and write your tag (i.e.: 1.0.3-build)
If your keys are good to go you should see some magic happening, and your artefact being deployed to the Acquia Cloud remote server. Now simply go to Acquia Cloud, select the tag that you have just created and deploy it in your environment. 
All done… although now I am thinking on changing the title of the article… not that short after all :-)
Bonus: Some commands
- Rebuild your local with the remote db:
blt sync
Equivalent to: drush sql-sync @remote @local

Ansistrano, deploying Drupal with Ansible

Last months have been pretty busy here at BBC Worldwide with some of the projects we've been involved in.

In my case, one of the main areas I’ve been trying to improve (apart of the daily busy routine) is our devops / CI approach. The previous approach was using Chef, but it was not really adopted by the developers (which meant that after some months, the system was broken) and we were lacking some fundamental things (like integration with the production system, a real CI flow, etc…).

On the other hand, my previous experience with puppet was that the system grew too much to be easily maintained, specially if you don’t have a big dedicated devops team. To sum up, during last months research I was pretty amazed with Ansible, it's amazingly simple, very flexible and a truly joy to maintain. So, to me, the way forward was Ansible.

So, we started rewriting some of the old broken features in Chef and, sooner than later, we found ourselves reinventing the wheel. Some features were custom things, like triggering "drush cc all”, executing grunt, phpcs, etc... but obviously lots others were not… well, we are not the first team in needing an apache and mysql database, are we?

And deployment is one of these things that I was not too keen to reinvent. It would be pretty simple with Ansible, to be honest, but why not use something that is already tested, works well and at the same time give some love back to the community? Enter Ansistrano.

Ansistrano is a deployment tool based in Ansible. The relation with Capistrano ends just here, with the name similarity (no code base was harmed during the process). For more information about Ansistrano please visit the official repository:

- Step 0. Install ansistrano (deploy and you’ll probably be interested in the rollback too):

ansible-galaxy install carlosbuenosvinos.ansistrano-deploy carlosbuenosvinos.ansistrano-rollback

- Step 0. Clone the deploy repo in the folder you’ll be using the app. Let’s say we’ll be working in ~/my-app-build :

git clone ansistrano-deploy

Notice that we are cloning the deploy repository.

We’ll be using the latest stable release, list tags:

vagrant@vagrant-ubuntu-trusty-64:~/my-app-build$ git tag

at the moment, the latest stable release is 1.4.1, so:

git checkout 1.4.1

Step 1. Now, the ‘tricky part’. We are going to write a file where we’ll execute all the magic. Let’s call it build-my-app.yml:

- name: Deploy example app to
  hosts: all
    ansistrano_deploy_to: "/var/www/myapp.local"
    ansistrano_keep_releases: 3
    ansistrano_deploy_via: "git"
    ## GIT pull strategy
    ansistrano_git_branch: develop
    ansistrano_git_identity_key_path: ""

    - { role: ansistrano-deploy }

Notice that the role we have at the end is just the deploy repository cloned from Ansistrano ( You can change the name, as I've done in this example (ansistrano-deploy) but you'll have to upgrade the roles variable in your yml (again, as shown in this example).  

Step 2. Run deploy:

ansible-playbook -i "localhost," -c local build-my-app.yml -vvv

Instead of specifying localhost you could also use a hosts file, as recommended in the official documentation. This is also going to give you the freedom of deploying your app not just in your local environment, but potentially in any remote server, i.e. aws, digital ocean, etc...

Step 3 (optional). From here, the limit is the sky. In our case, we have some complex deployments running grunt, drush, clearing cache… The advantage here is that ansible is pretty flexible, so you could for example add your own tasks in your deploy file (build-my-app.yml), i.e.:

  - include: goodfood/tasks/apt.yml

The right, official way of doing this is using the hooks that ansistrano itself offers you:

  # Hooks: custom tasks if you need them
  ansistrano_before_setup_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-before-setup-tasks.yml"
  ansistrano_after_setup_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-after-setup-tasks.yml"
  ansistrano_before_update_code_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-before-update-code-tasks.yml"
  ansistrano_after_update_code_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-after-update-code-tasks.yml"
  ansistrano_before_symlink_shared_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-before-symlink-shared-tasks.yml"
  ansistrano_after_symlink_shared_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-after-symlink-shared-tasks.yml"
  ansistrano_before_symlink_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-before-symlink-tasks.yml"
  ansistrano_after_symlink_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-after-symlink-tasks.yml"
  ansistrano_before_cleanup_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-before-cleanup-tasks.yml"
  ansistrano_after_cleanup_tasks_file: "{{ playbook_dir }}/<your-deployment-config>/my-after-cleanup-tasks.yml"

where playbook_dir is the folder where your yml file lives.

That's it. Simple, elegant, and really powerful, I love it :-). Next episode, we'll talk about the rollback artifact.

Notes: Amended Step 0, as you don't need to install the playbook through the ansible galaxy, just cloning would do. Thank you Carlos Buenosvinos.

Software Craftsmanship

Software Craftsmanship is a mindset— a lifestyle that many professional developers adopt. Software craftsmen live and breathe software. They see software as a craft and are committed to do whatever they can to master their craft

Ingeniería y cafe

"Un ingeniero es una máquina que convierte café en diseños, construcciones y líneas de código." Parafraseando a Alfréd Rényi


Bad code

Don’t comment bad code— rewrite it.

Brian W. Kernighan and P. J. Plaugher1

Development phrase of the day

If we do things that way, we are going from Spagetti Code to Lasagna Code.

Howto use Lazy Loading in Symfony2 (and Drupal 7 / 8)

Lazy Loading is a software design pattern which basically allows our classes and objects to be a lot lighter. Faster code, faster applications, less memory used in runtime. The great Martin Fowler says about Lazy Loading:

An object that doesn't contain all of the data you need but knows how to get it.

The key is that your "real" objects are not going to be instantiated unless they are going to be used. How that can be achieved? Easy, with what it is called a Virtual Proxy. As in every project, you can always code your own implementation, but the key about design patterns and software engineering is to reuse as much as possible. And regarding Lazy Loading, Symfony 2 has a nice implementation called Proxy Manager Bridge, which does exactly that in Symfony 2.

Recently we discovered that our implementation of Lazy Loading was not working properly in Drupal 7. We were using a custom module which we created in Capgemini, Drupal Symfony Inject, to inject our own implementations of Symfony 2 classes in Drupal. The module works great, but for some reason the Lazy Loading was not working, the objects were always having the real implementation of the object itself instead of the proxy (for more info, check the documentation in Symfony 2 about Lazy Services).

The solution is relatively easy (not as much as finding it), and I commited a patch for that, so Drupal Symfony Inject should not have that problem anymore:

A different question is, how to use Lazy Loading in our projects when we are not using Symfony 2 framework but its components. One of the errors which we were doing in the Drupal Symfony Inject module was that we were not loading the Proxy Manager Bridge, which makes the integration of Proxy Manager, your code and some other Symfony 2 components.

At that point we were quite lost, not many people has done before that integration between Drupal and Symfony 2 Lazy Loading, so we had very few people to ask, even inside Capgemini itself, and even fewer documentation to consult. Fortunatelly there are some interesting pieces of code in every well designed software. I am talking about test units:

The most interesting part in lines 34 and 37:

$builder->setProxyInstantiator(new RuntimeInstantiator());

That part is essential, it will instantiate the Proxy Manager and substitute your Object with an instance of that Proxy.

We just need to do one last step, indicate that our object will use Lazy Loading:


From this point, the next time you load your object:


if you ask for the class of this object it will identify itself as a Lazy Proxy:


 That state will remain until you ask the object to return something, basically when you use one of its methods:


Now that object will say that he is the real class, something like that:



More information:

Profiling PHP and Drupal with XDebug (In OSX)

Problems with a rogue app you built (maybe not you)?

Just some links which I found useful in order to debug/profiling your app:

Run it in you Mac with OSX:

Sometimes you need your profiler to be executed everytime. You can do that with this:


This is my whole xdebug.ini:

; Enable xdebug extension module











Other general links:


Composer and Symfony2 in Drupal 7


Developer definition

Programmer: an organism that turns caffeine and pizza into software :-D