Platform.sh

How to Kill a Giant

  Drupal 7 has been there so long, and it offered us unprecedented flexibility to build some pretty huge projects -- special kind of beasts that have nothing to do with the original "Drupal-as-a-CMS" paradigm. Think about Drupal sites that behave as OAuth2 servers; or sell content access, or prorate prices and bill them monthly; or news portals that are also exposing the API's for popular mobile apps; or membership databases of really big organizations. Sometimes, these projects would be so big and so crucial to our businesses that there would simply be too much disruption if they went offline.  But Drupal 7 is getting closer to its end of life. We have good migration scenarios for most of the use cases. However, the above giants are marginal cases which cannot simply be migrated to Drupal 8. And even if they could — that may result in building a new giant which would have to be killed once again at Drupal 8's end of life. Sometimes, a transition to something service-oriented may make more sense. This session suggests a strangler application pattern in a Drupal 7 project. Martin Fowler describes the strangler application as “…a new system around the edges of the old, letting it grow slowly over several years until the old system is strangled”. In our PHP/Drupal realm, that means: decoupling the frontend of a Drupal 7 project; placing a middleware API proxy between the frontend and Drupal; finally replacing individual parts of the old system with the newly developed ones This approach promises zero downtime and makes no assumptions on what will be the resulting tech stack. The decoupled frontend can be a GatsbyJS project, or a React app, or even a static HTML served from the middleware. And the middleware itself can be a NodeJS/Express app, or a Golang API proxy, or something third. The backend can be replaced with a Drupal 8 monolith, or multiple Drupal 8 projects, or with a full-blown microservice architecture. The sweetest part of the pattern is that even if you make an error in the architecture of your backend, which will require serious refactoring, you will be able to correct it without a downtime.

CI made dead simple with Drupal 8, GitLab and Platform.sh

So you learned the importance of tests. You also learned that they are made pretty simple with Drupal’s PHPUnit framework. You may have even invested some time to set up behavioral tests using Behat Drupal Extension. Now it’s time to bundle all the testing together in a nice automated pipeline. CI promises faster code review and fewer regressions on each deployment. It used to come with a high price: the need to set up Jenkins, Apache Ant, configure jobs and whatnot. It was a relatively simple task for ops people, but not for the PHP developers. So we’ve got some cloud-based CI tools, which are great, simple to set up, free for open source projects, but tend to get pretty expensive for the rest. This session proposes a cheap and easy-to-set-up alternative. It will demonstrate: Using GitLab server to host your own Git repositories and build powerful CI pipelines; Automated code testing for every single merge request, which saves lots of time for code reviewers; Automated deployment to Platform.sh environments for human review; One-click deployment to the production environment; Thinking outside of the box to optimize the CI workflow. The best thing about the proposal is that it will be entirely up to you how complex you want it to be: start simple and add new steps to the build as you climb up the learning curve.