Sunday, July 5th, I did my livestream exploring DDEV-Live. DDEV-Live is the hosting counterpart of DDEV-Local. I use DDEV-Local as my local development stack, and I love its simplicity for running local environments with Docker. You may remember the company as DRUD - Destroy, Rebuild, Update, Destroy – and DDEV-Local as just DDEV. They have centralized on the DDEV brand name focusing on just the Local and Live products.

There were a few hiccups while getting started – which I totally expect the first time trying new product! I often skipped ahead of some of the documentation, and the user interface (or command line) needs to expose a little bit more metadata (I'll explain later.) DDEV-Live has been an enterprise hosting environment, so the end user features are still being flushed out. All in all, I'm excited to keep using the product.

To begin, you sign up with your email, GitHub or Google account. It's powered by Firebase Authentication. If you use Brave browser, you'll need to disable shields for this to work. During your account setup, you will setup your account name and organization name. Be aware of what you set as these will be needed later on. I kind of buzzed through and had a hiccup down the road (I didn't know my organization name.)

You work with DDEV-Live by connecting their GitHub App to your personal account or organization. There is a DDEV API token you can use for integrating with the command line tool in your continuous integration tool. From there, everything is done via the command-line. Their Getting Started documentation shows how to install the command line. For macOS it is a Homebrew recipe.

Once you have the GitHub App installed, you can authenticate with the command-line tool.

ddev-live auth

The auth command will launch a browser. Since you are already logged into your DDEV dashboard, it should automatically complete the OAuth handshake and authenticate your local device. However, if you are like me, it did not launch the correct browser (my computer defaults to Chrome, but I actually use Brave. Long story, explained in my live stream.) If the browser launch does not work, you can explicitly provide your DDEV token

ddev-live auth --token $DDEV_LIVE_TOKEN

A hindsight lesson: When I did auth, I should have specified my default organization using the --default-org flag. Organizations in DDEV-Live are like namespaces in Kubernetes. You can read more about them in the DDEV-Live Organizations documentation. When I signed up, I set my org to glamanate thinking it was going to be my site name. Whoops! There currently isn't a user interface to revealing this information and luckily DDEV team members were on the call and helped bail me out.

If you do not specify a default organization you will need to provide it with every command thereafter. This isn't too cumbersome if you are used to working with Kubernetes and having resources in different namespaces for each application. 

To create a site, you use the ddev-live create command. When you create a site, you provide the type of site you will be creating – Drupal, TYPO3, or WordPress.

~ » ddev-live create site --help
Launch a new site

Usage:
  ddev-live create site [command]

Available Commands:
  drupal      Create a Drupal site
  typo3       Create a TYPO3 site
  wordpress   Create a WordPress site

When you create the site from the command line, you specify the site's name and the GitHub repository that contains the code for the site. Using the --help flag explains various settings when setting up your new site.

For instance, here is the command that was required for creating a new Drupal 9 site from the Composer template provided in the Local Development Guide on Drupal.org.

ddev-live create site drupal \
   ddev-live-d9 \
    --github-repo mglaman/ddev-live-d9 \
   --php-version=7.3 \
   --drupal-version=9 \
   --docroot web \
   --run-composer-install

Here is a breakdown of what is going on with that command:

• ddev-live create site drupal: We're creating a new site that is setup for hosting a Drupal site.
• ddev-live-d9: This is our site name.
• --github-repo mglaman/ddev-live-d9: This tells DDEV-Live to pull code from the GitHub repository mglaman/ddev-live-d9.
• --php-version=7.3: This one is important! The default PHP version for Drupal is currently 7.2 and Drupal 9 requires 7.3.
• --docroot web: When using the default Composer template, all assets that should be served by the web server exist in the web directory, like index.php. 
• --run-composer-install: This ensures that Composer is executed to install your dependencies during the build process for your site.

You may also provide a --branch flag to specify what branch should be monitored for changes to deploy. There is also --composer-args, which allows you to pass arguments to composer install when your site is building. This can be used to ensure --no-dev is passed to prevent developer dependencies from installing.

For example, the command could be expanded to support --no-dev --prefer-dist --optimize-autoloader --apcu-autoloader --no-suggest --no-progress. (This is my normal composer install argument for production builds.) You provide each argument without the dashes separated by a space.

ddev-live create site drupal \
   ddev-live-d9 \
    --github-repo mglaman/ddev-live-d9 \
   --php-version=7.3 \
   --drupal-version=9 \
   --docroot web \
   --run-composer-install \
   --composer-args no-dev prefer-dist optimize-autoloader apcu-autoloader no-suggest no-progress

After you create your site, you need to wait for it to deploy. You can monitor the status of your site using the describe command.

Note! If you are like me and forgot to configure anything, the ddev-live config drupal command has you covered. I fixed my site's Composer build command to have all of those arguments using the following command:

ddev-live config drupal ddev-live-d9 --composer-args no-dev prefer-dist optimize-autoloader apcu-autoloader no-suggest no-progress

When we run ddev-live describe site ddev-live-d9, you get various information back about your site's deployment.

DDEV-Live listens for pushes to your repository to trigger deployments, based on the branch for the site. I was able to trigger a deployment via a commit and kick off a Kubernetes deployment. There currently is no way to monitor a deployment or see ones currently in process. I had to just keep running describe on my site to see when healthy checks returned OK.

I was able to make backups of my site's database and files so that I could pull them locally. Whenever you trigger a backup command, a remote job is created and a describe command is provided to check for the job's completion. Again, there is no user interface for tracking items in progress. You can only run the describe command to see what their current status may be.

Here's the cool part: With DDEV-Local v15 (just released!) you can integrate with DDEV-Live to work on your site locally. This allows you to run ddev config ddev-live to specify what DDEV-Live site your local environment is for. Then, you just run ddev pull to get the DDEV-Live site's database and files imported locally! Note, file sync is based on the last file backup.

One of the things I appreciate most: their openness to feedback. The dashboard provides a feedback form. Their command line even has a shortcut for launching this form: ddev-live feedback.

Over all, it felt pretty nice. I haven't been playing with my Kubernetes cluster as much as I thought I would, so I'm basically burning money for no reason. At $15.00 a month for personal sites, that isn't too bad. 

Interested? Make sure you catch the live stream recording below. You can also use the coupon code mglamanblog to get 50% for your first month when you sign up by July 24th.