Rebuilding jeffbeeman.com: My local development environment and workflow

Posted by Jeff Beeman on Sun, 05/20/2018 - 13:20

Last week I talked about setting up a new project using BLT, Dev Desktop, and Lightning. Today, I’ll talk more about my local environment setup and give a brief overview of my development and deployment workflow.

Dependencies

As I discussed in the last post, PHP, Composer, and Git are all installed via Homebrew:

brew install php71 composer git;

A global version of Drush (8.1.15 as of this writing) is supplied by Dev Desktop. I find this global Drush version continues to be useful for older Drupal 7 projects I continue to maintain and for projects for which I haven’t yet updated alias files or do not yet contain Drush 9-compatible commands.

Drush for this project, though, is locally vendored (BLT requires Drush as a dependency). Drush takes care of discovering the right version to use via the Drush Launcher built into the global Drush 8. So, I don’t need to worry about calling the wrong version of Drush for my project. If you’d like to add Drush 9 to your own Composer-driven project, there are instructions over in the Drush documentation.

Local environment configuration

Dev Desktop provides its own versions of things like PHP, Drush, and MySQL. Because I’m running PHP and Composer via Homebrew but also running Dev Desktop, I’ve done a few things to setup my local environment so it utilizes the right tools from the right places.

The lines below from my .bash_profile provide path settings account for the locations of the various tools I’m using.

export PATH="/usr/local/bin:/usr/local/sbin:$HOME/bin:$HOME/.composer/vendor/bin:$PATH"

# Add Dev Desktop settings and paths.
# Does not add Dev Desktop's PHP path; PHP is installed via Homebrew.
export DEVDESKTOP_DRUPAL_SETTINGS_DIR="$HOME/.acquia/DevDesktop/DrupalSettings"
export PATH="/Applications/DevDesktop/mysql/bin:$PATH"
export PATH="$PATH:/Applications/DevDesktop/tools"

I keep my .bash_profile configuration in a public Github repository, so feel free to check out jrbeeman/dotfiles if you’d like to see other potentially useful config to pull into your setup.

Editor extensions and configuration

I’ve been using Microsoft’s Visual Studio Code for nearly all development over the past year, and I think it’s great.

The following extensions have been useful in turning VS Code into a robust PHP IDE. Note that some of these extensions were installed for JavaScript development, and I’m including them here as many Drupal projects require both.

  • Apache Conf
  • Code Outline
  • Document This
  • ESLint
  • Git History
  • Markdown All in One
  • markdownlint
  • MDTools
  • PHP Debug
  • PHP DocBlocker
  • PHP Formatter
  • PHP Intelephense
  • Snippets and Syntax Highlight for Gherkin
  • TSLint
  • Twig
  • Vagrantfile Support
  • vscode-icons

VS Code supports user- and workspace-level (project) configuration overrides. Here’s what I’m using.

User settings

These user settings perform basic font and text display configuration and turn on the nice icons provided by vscode-icons.

{
  "editor.fontSize": 14,
  "editor.wordWrap": "on",
  "workbench.iconTheme": "vscode-icons",
  "editor.tabSize": 2
}

Workspace settings

These workspace settings tell VS Code to treat Drupal’s various funky file extensions as the right language (files.associations) and to ignore several different folders when building its index (files.exclude). The primary change with files.exclude was the “deploy” folder, which can really confuse VS Code if not ignored due to it containing a full copy of the application after creating a build.

{
  "files.associations": {
    "*.module": "php",
    "*.install": "php",
    "*.inc": "php",
    "*.theme": "php",
    "*.info": "ini"
  },
  "files.exclude": {
    "**/.git": true,
    "**/.svn": true,
    "**/.hg": true,
    "**/CVS": true,
    "**/.DS_Store": true,
    "deploy": true
  }
}

General workflow

Committing work to Github

As I work, I’m pushing my changes out to Github. I won’t go into too much detail on that aside from saying the .gitattributes and .gitignore files provided by BLT do a lot of the heavy lifting you’d normally need to do when first configuring Git for a Composer-driven Drupal project. You can check out what BLT provides here:

Deploying to Acquia Cloud

At given points during the development process, I feel ready to run a build and deploy those changes to Cloud.

In order to deploy to Acquia Cloud using BLT’s deploy commands, I first had to configure blt.yml with Acquia Cloud as a remote:

git:
  default_branch: develop
  remotes:
    cloud: '[email protected]:exodar.git'

Because of Composer and BLT, adding new modules and deploying the change to Acquia Cloud is as easy as the three commands below, where I’ve added the Markdown module to the Exodar project:

composer require drupal/markdown:^1.2;
git commit -am "EX-000: Add markdown-8.x-1.2";
blt artifact:deploy --commit-msg "EX-000: Example deploy to branch" --branch "develop-build" --no-interaction;

I’ll go into greater detail about BLT’s artifact build and deploy commands in later posts. Most deployment processes will be more complex than this, especially when working with a team. For example, the brief process outlined here doesn’t account for anything related to configuration management, automatically enabling newly added projects after deployment, etc. Those more sophisticated aspects of a site deployment workflow will come later as I continue to modernize the workflow for my personal site. For now, this is a good start and allows me to rapidly develop my personal site while still leveraging Composer and BLT.

Wrapping up

With my local development workflow setup, now I can rapidly iterate on my project using Composer to add new dependencies, Drush to configure them, and BLT to deploy them. I've also got a great IDE configuration, so working with my project's code is a joy.

Tags