Drupal development workflows: To yield returns, you need invest early

(Este post fue originalmente escrito en español)

Since the agile dev manifesto of 2001, it took force prioritizing functional software over extensive documentation. Under this priority, we got used to install a Drupal, download some modules, activate them and within hours have a working prototype from which would continue the development of our site.

But, how to keep the code in the future?

Eventually we will have many dozens of modules, it is not uncommon to have a hundred of them in a Drupal installation, especially in a commerce.

The issue about having unstructured code, is in the future, because implement changes will become complex and slow without breaking what is already done. This goes against one of the values ​​of the manifesto; The ability to respond to change.

But fear not, there are solutions.

In this article I will explain how to implement some techniques in your development workflow that although they are a little more initial work, in the long run it will save much time and hassle.

drush make: From many megas a few kilos

Drush is a Drupal tool that allows us to run multiple tasks through the command line interface (CLI), it is “the Swiss Army knife of Drupal.” One of its many features is the command drush make , it can create a code base “ready to use” downloading the Drupal core and modules from drupal.org or git repositories, and even apply patches downloaded or local. In practical terms it is a way to distribute or store a complicated package of Drupal in a single text file.

For instance:

api = 2
core = 7.x
projects[drupal][version] = 7.38
; views module
projects[views][version] = 3.11
; bootstrap theme
projects[bootstrap][version] = 3.0

A make file like this, will download the core drupal 7.38, the views module 7.x-3.11 and bootstrap theme 7.x-3.0. Please notice the ability to add comments, allows us to explain to use each module or set of modules, when we have dozens of these, we can humanly navigate this file.

Features: From SQL php

The features module along with features_extra and Strongarm and allow us to “download” the settings from database to code.

Through drupal admin at /admin/structure/features, you can export individual components (views, contexts, CCK fields, rules, etc) to file set (feature), which practically acts as a standard drupal module, which you can use in any other Drupal, brand new or in operation, with the ability not only enable it, but also to update it or even reverse it.

The idea is to save functionality that you create through modules and configurations into features, thus making them truly independent of the database, relegating db to the role of mere content store and not functionality. Thus those features that you created, you can use them in different environments (local, dev, test, ops) and even in other projects, or other clients.

Do you begin to visualize how long can you win?

If it’s about agility, git gives you wings:

If you’re not using git yet at your development, pause all you developments, study it –I hear there are excellent tutorials at piratebay–, and implement git over you projects, in a week and you’ll thank me, really. If already git is you co-pilot, you can skip to next point.

Git is an application for version control, basically you set it up to monitor a directory that contains your source code that is called repository (in the simplest case would be your public_html). And on this directory, as you go making changes, run a commit command that kind of save of each revision.

The commit have a space for a title and a description, and although at first it may seem tedious and even a waste of time to write them, in time, when your project becomes complex –and especially when you have to do roll backs ( restore previous revisions)–, it will be extremely useful and will save a lot more work than it costed originally to write them.

Pro Tip:
Even if English is not you native language, in some projects is worth keeping the git comments, internal code and documentation in English, so you could integrate developers overseas to you proyect.

Another marvel of git is its branching function, which allows you to work in several parallel branches of the same project, allowing you to work parallel and independently in different functions or corrections to your code. When you’re satisfied with your work in branch, you perform a merge operation, which will integrate all changes from your side branch, your main branch.

The third key feature is git push, allows you to send your repository to a git server, which together with the pull command, which brings new changes to your computer from server, enable multiple developers to work in parallel in the same project. Bitbucket is my favorite free provider, Github is popular too but you must pay to have a private repository.

Finally, if you are someone who are intimidated the command interface, or simply does not suit you, I invite you to try graphical alternatives to git.

If you a mac user, let me recommend you Tower , in my case I use it because having a friendly graphical interface, I tend to write more and better messages on my commits.

Putting all together: Adapt to your hosting

In the simplest scenario, assuming you are in a classic hosting, using git is completely at your discretion and you have to discipline you self to run periodically git commits in your local environment. You should organize your work in at least two directories, one for the source and the other for the build. In the first you keep your project.make and you custom modules, themes and patches; the second will be “compile” your final drupal.

This task could be done manually, but is absurdly tedious. So at least I recommend you do a batch file that do for you each time, cleaning the build directory first, then running the drush make, and finally copying or creating symbolic links to your own modules and themes.

If you’re a friend of grunt, I recommend drupal-tasks; It is a plug-in to automate the build and testing of drupal, it even comes with a Yeoman generator that can do the initial project scaffolding for your.

Pantheon.io is a hosting platform that allows direct access via git and manage “up there” the commits and banching, generating independent copies of environments for each branching. If you already work in Pantheon, but you are not using these capabilities, my advice it checkout the Saul Willers slides on the topic exposed at June 2015 drupal Chile meet up.

In my current view Platform.sh has better rates and features than Pantheon, making it is my current favorite. In this scenario, once you have created your project through the web interface, you must download the Platform CLI (command line interface). Then executing a platform get, it will download the project and organize it into four directories:

  • builds: Stores the different builds that you generate.
  • repository: Stores your original source only.
  • shared: Stores drupal’s files directory and your settings.local.php
  • www: It’s a symbolic link to the latest build (for the convenience of your local web server).

Assuming you want to develop local you should create a settings.local.php file in your shared directory with at least your SQL credentials, like this:

<?php
// Database configuration.
$databases['default']['default'] = array(
'driver' = 'mysql',
'host' = 'localhost',
'username' = 'user',
'password' = 'pass',
'database' = 'db-name',
'prefix' = '',
);

And finally you need to configure your local web server to use www as the web root of your site, in this way it’ll always be on your latest build.

Now that you have everything set up, you must create a file project.make at you repocitory root directory. Platform will do the work for you then, either when making a local build trough platform build command at the project directory. Or when the build to run on their servers, which occurs every time you do a git push, Platform receives your source code and generates a build, deploying it in a unique environment.

If you like complications, you can highly customize the build in Platform to even compiling your sass or less on their servers to automatically when run a git push.

Pro Tip:
You can place a php.ini file in the root directory of your repository, to override Platform’s default.

In conclusion:

With a little more work in the initial setup of your workflow, you can get great savings of time in the future for a project, increasing your efficiency, speed and quality of response to you customer’s requirements.

Now you get this ideas, ask you self following questions:

  • Which of your Drupal projects could from experiencing these forms of work?
  • Which of your projects would benefit more if you implement these methods?
  • What will you do with the time that you win? Seriously, I invest it wisely. Time is the most valuable asset we have in finite human experience.

I invite you to share this post with your team or collaborators. And if you implement these methods, I would like to hear how it turn out, do not hesitate to contact me when you are 2 or 3 months using this methods.

Advertisements

Agregar un comentario

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Cambiar )

Twitter picture

You are commenting using your Twitter account. Log Out / Cambiar )

Facebook photo

You are commenting using your Facebook account. Log Out / Cambiar )

Google+ photo

You are commenting using your Google+ account. Log Out / Cambiar )

Connecting to %s