Really large teams of Drupal developers, even larger QA teams, a heavily weighting "overload" of custom code, a whole "ecosystem" of repositories... these are just some of the particularities of an enterprise site building process. A process which, if not ideally structured and backed up by a "healthy" Drupal development routine, with a few basic rules, is prone to error and to "surprise" events right before launch day. Therefore, let me try and make a sort of a "draft" list of 7 best practices to stick to when you're Drupal 8 enterprise site building:
1. Big NO to Checking Security Measures Off Your List On Launch Day
… for this is such a reckless thing to do and you know it (and we are talking about enterprise Drupal 8 site builds here after all)!
Here's a list of security steps to check off your list “from day 1” of development:
- http set-ups
- admin account password set up following a complex password policy (please tell me that you're not still using, as passwords, the names of the new sites that you're developing till almost their launch days!)
- SSL certificates setting up
A production infrastructure shouldn't mean “building first and safeguarding your new Drupal 8 build last”! Better safe from day one than sorry on launch day, don't you agree?
2. Repositories and Projects: Embrace Minimalism!
… whenever possible and if your site building context permits, of course!
Resist temptation (that Composer for Drupal site development makes almost impossible) to pile up more and more separate repositories, each one corresponding to one custom theme or module!
Now in order to convince you to ignore your instinct “telling” you to put together a whole “infrastructure” of individual repositories, I'd better try and explain the “harms” that this Drupal 8 enterprise site building habit can do:
- you might end up with cross-repository dependencies prone to human error: you or other Drupal
developers from your team might overlook the fact that all the involved pull requests need to be made in a certain order. In other words: it's also much more convenient handling just one single repository and, implicitly, only a single pull request, too
- you might also overlook the second pull request required: the one in the composer.lock (in the site repository), which should always come after the one in the module repository. And this only leads to confusing your QA team
- you might also deal with a co-dependent repositories situation, one that no one from your team is actually aware of; and you can easily avoid it by testing your new site build's modules as independent modules. As stand-alone modules.
3. Remember #Cache When Working on a Drupal 8 Enterprise Site Building
And I can fully understand why it's so easy for you to skip to use the addCacheableDependencies. The habit of creating render arrays, like we used to do in Drupal 7, might still be well-rooted into your site development “routine”.
#Cache best practice no. 1: Always keep in mind to render cache dependencies!
#Cache best practice no. 2: remember to enable your cache on your local environment when you're testing it. Write code with your cache disabled, but always keep in mind to enable it back when you run your tests!
4. Set Up Automated Reverts and Backups
… for all those unwanted scenarios when your deployment fails and you want your site (both its file system and its database) to go back to its “pre-deployment” phase.
How could you make all this reverting and backing-up happen automatically?
Well, for instance the AWS and all its “kindred” platforms provide you with utilities and API that you can leverage for managing your backups and your reverts.
5. Branches: Start Small and Gradually Grow Big (Only) If Needed
My recommendation is quite similar to the one I've given regarding repositories: restrain yourself from piling them up!
Especially when some of them won't even be used!
Stop before you rush in to create your stagging, your QA, your master, your develop branches. Just take some time to reflect on whether they will, indeed, have their own specific well-defined roles.
If not, simply settle for just one master branch. At least at that phase of the Drupal 8 enterprise site building!
It's from that single branch that you can, later on, enrich your “ecosystem” of branches.
Once you've realized that you do have a specific environment for each one of them and that, yes, they're needed and will be used.
6. Parallel Projects: Avoid Them in Drupal 8 Enterprise Building
Now let's assume that you have no choice, that the given site build context demands several environment-specific branches.
Well, it's the “perfect” context favoring parallel projects, you know. This if you ignore merging them “upstream”.
Since in Drupal 8 Composer enables you to have multiple composer.json files, each one standing for one branch, you run the risk of ending up with two different websites:
- one that your visitors can access
- the other one that you (and the other developers in your team) and the QA team can use
The “perfect” scenario causing confusion within teams!
Note: another best practice that you shouldn't underestimate when you're involved in Drupal 8 enterprise building is that of applying changes to the new site build's “skeleton” once in each one of the branches!
7. Go for “True-to-Life” Downsyncs
I know, I know: transferring content (heavy databases and file systems) between two environments is the last thing on your mind, the last task on your priorities list when you're Drupal 8 enterprise site building!
And yet, it makes all the difference!
Both to you, to your team of Drupal developers and to the QA team. They'll then know what the production infrastructure is and their code writing/testing tasks will be carried out much quicker!
And voila! These are the 7 best practices to incorporate into your own routine of Drupal 8 enterprise site building if you want your team to be more confident on launch day and to win your clients' trust in your work ethic.
Are there other “commandments”, that you never break, on your personal list?