Getting Started with a Real World Application on platform.sh

This is the second in a series of articles involving the writing and launching of my DurableDrupal Lean ebook series website on platform.sh. Since it's a real world application, this article is for real world website and web application developers. If you are starting from scratch but enthusiastic and willing to learn, that means you too. I'm fortunate enough to have their sponsorship and full technical support, so everything in the article has been tested out on the platform. A link will be edited in here as soon as it goes live.

Diving in

Diving right in I setup a Trello Kanban Board for Project Inception as follows:

Project Inception Kanban

Both Vision (Process, Product) and Candidate Architecture (Process, Product) jobs have been completed, and have been moved to the MVP 1 column. We know what we want to do, and we're doing it with Drupal 7, based on some initial configuration as a starting point (expressed both as an install profile and a drush configuration script). At this point there are three jobs in the To Do column, constituting the remaining preparation for the Team Product Kickoff. And two of them (setup for continuous integration and continuous delivery) are about to be made much easier by virtue of using platform.sh, not only as a home for the production instance, but as a central point of organization for the entire development and deployment process.

Beginning Continuous Integration Workflow

What we'll be doing in this article:

Why won't anyone listen to Nedjo?

When he says the Drupal 8 Configuration Management system is only listening to one use case?

One reason no-one listens to Nedjo Rogers on this subject is that what he's saying is not that simple to understand. But I assure you it's well worth the effort. He's saying that the Drupal 8 Configuration Management system is built around a single use case that favors a certain enterprise need, namely that of single site configuration stabilization and propagation to other environments, principally live.

In his initial article on this subject (Bibliography #4, Nedjo Rogers) Nedjo wrote that the fact that “Sites own their configuration, not modules” (as stated in Bibliography #3, Alex Pott) constitutes nothing less than “a seismic shift in Drupal that's mostly slipped under the radar”. Nedjo first reviews the history of exportable configuration in Drupal, and correctly highlights the fact that there are two main use cases involved:

  • To share and distribute configuration among multiple sites.

  • To move configuration between multiple versions of a single site.

“By and large, the two use cases serve different types of users. Sharing configuration among multiple sites is of greatest benefit to smaller, lower resourced groups, who are happy to get the benefits of expertly developed configuration improvements, whether through individual modules or through Drupal distributions. Moving configuration between different instances of the same site fits the workflow of larger and enterprise users, where configuration changes are carefully planned, managed, and staged....”

“If anything, the multiple site use case was a driving force behind the development and management of configuration exports. The Features module and associated projects - Strongarm, Context, and so on - developed configuration exporting solutions specifically for supporting distributions, in which configuration would be shared and updated among tens or hundreds or thousands of sites.”

“For Drupal 8, however, the entire approach to configuration was rewritten with one use case primarily in mind: staging and deployment. The confiugration system "allows you to deploy a configuration from one environment to another, provided they are the same site."

If this is the case, then we really need to get to the bottom of this issue. The objective of this article is to briefly summarize the whole debate (see Bibliography), remove any items that are blurring or clouding the issue, and then underline three times those points that really deserve not being kept “off the radar” and which I hope others will delve into so that we can get a clear picture of perspectives and solutions (many of which Nedjo himself, and others, are spearheading already in third party modules; see below). It's an important question: what's in store for us in terms of industry-wide best practices for Configuration Management in Drupal 8, taking into account all important use cases? And it's a question that Nedjo took the trouble to raise in the Drupal Community as far back as January, 2012. But no-one listened. 

Five Things I didn't know about Platform.sh

I want to share some exciting things I'm only just finding out about Platform.sh (the “Develop, Deploy, Rinse, Repeat” continuous delivery cloud platform for Drupal, Symfony and PHP based projects) that look as if they might have a lot to do with folks finding a straightforward way of enabling a truly Lean process applied to website and web application projects. We'll cover five things I didn't know about Platform.sh:

  1. The Standard Platform Workflow is just what modern, serious PHP, Symfony and Drupal developers might expect and can easily be set up for all team members.

  2. The Standard Platform Architecture is container based and scales tremendously well for most use cases.

  3. They don't use Varnish! They use CDNs (content delivery networks)!

  4. There's an Enterprise Platform with its own truly scalable architecture and unique benefits

  5. A chance to get a first-hand report from someone actually using the Platform.sh Enterprise Platform.

DrupalCon Latin America 2015 Bogotá will live on as one of the classics

Grass roots enthusiasm, D8 teen spirit, much needed long absent leadership and community courage facing up to critical issues should overflow into DrupalCon Los Angeles in May

An incredible DrupalCon, DrupalCon Latin America, ended a couple weeks ago and I haven't seen any cool DrupalCon wrap-ups capable of really sharing with the rest of the Drupal community what an extremely well-organized and just plain special community experience it was. I am sure I'm not the only one who felt completely invigorated by it all. Let's take a look at why, and see how we can make it contagious.

Great Venue
Attendees from all over
Quality of presentations
Drupal 8 properly positioned
Now we know when to start switching to D8
Much Needed Drupal leadership
Huge participation in the Sprints and beyond

Desgrabación de mi presentación sobre DurableDrupal Lean UX+Dev+DevOps Drupalcon Latin America

Desgrabación de la Presentación en el DrupalCon Latin America 2015

Poner en pie una fábrica de DurableDrupal (Drupal Duradero) en base de un proceso Lean reutilizable

[Bajar el pdf de 18 páginas al pie de la página]

Ya que el sonido de la grabación de mi presentación quedó muy bajo en volumen, quiero presentar la desgrabación con la esperanza de que mi mensaje llegue a la mayor cantidad de personas posible.

El video de la presentación en sí se encuentra aquí: https://www.youtube.com/watch?v=bNbkBvtQ8Z0

Los diapositivas: http://awebfactory.com/drupalcon2015lean/#/

Para cada diapositiva, incluyo a continuación el link al slide y el texto correspondiente del video.

En algunos casos hay correcciones inevitables o he extendido el texto para su mejor comprensión. También he traducido diapositivas importantes y agregado algunos comentarios para incluir puntos de suma importancia que no fueron mencionados en la presentación por falta de tiempo, como el Kanban y sus características.

El artículo como consecuencia se extiende bastante, pero espero que resulte de utilidad para quienes se interesan por la cuestión del proceso Lean en los desarrollos con Drupal.

Mi plan es publicar en breve un libro que integre estos conceptos en la práctica con un ejemplo concreto de desarrollo de una aplicación web en Drupal 7 y 8.

Syndicate content