How to deploy from a branch, commit, or tag

Tree branches silhouetted against a blue sky with sun flare

Have you ever found yourself needing to deploy a very specific version of your web project? Perhaps you wanted to deploy a commit with the latest code for testing, or examine and share some new ideas in a feature branch with collaborators on the other side of the world. Or maybe you’d like your published production site to point to a tagged release of your codebase. 

Centering your work around Git supports safe and collaborative work, but how do you continue that best practice all the way to production? The DDEV-live platform solves the problem of connecting a Git workflow from development through to deployment by offering the ability to specify a Git branch, tag or commit to pull code from.

Git best practices and deployment limitations

When you’re following a Git-based workflow, you generally have multiple pieces of work tracked in branches within the repository. There’s the “main” branch (the source of all truth), various branches for testing, staging, integration, as well as development branches with features, bug fixes, and midnight inspirations. During the project’s lifecycle, it’s likely only the basic testing, staging, or production branches that get deployed in remote environments. 

But what if you want your production environment to pull code from a branch called “finalfix3” instead of being pinned to “master”? Or you’d like to build a unique QA environment from a single commit, separate from the deployment workflow. For hotfixes and random features the client suddenly wanted to see in a production-like environment (ie their browser), this can require more set up and configuration than it’s worth, leaving you considering whether you could just use your machine as a host for a few days (useful! but impractical in a complex work-from-home workflow).

Connecting and referencing your existing Git project with some web hosts requires a bunch of tools, a bunch of set up, and can be locked in to prescribed workflows. The inability to extend the structure and process you’ve built for your work limits what you can accomplish.  Working with branches locally is massively flexible when tracking various pieces of work in progress, as well as when merging work to build a release. Tagging chunks of work in Git is a standard best practice for tracking versions or releases for a project in the long term (a nicely documented example is the Drupal project, which uses branches for versions and tags for releases). 

So, how can you extend your project structure and Git best practices throughout your development lifecycle all the way to deployment?

Deploy any branch, tag, or commit to DDEV-Live 

The DDEV platform is specifically built with a Git-based workflow in mind. Any time you create a “site” with DDEV-Live, you must reference a Git revision to pull the code from. A site can be created from a commit, tag, or branch from your existing GitHub or GitLab repository, creating parity for Git providers on the platform. 

What does this look like in practice? You will specify the Git revision to deploy on DDEV-Live when creating a site with a command such as this example (see more examples in the CLI docs) referencing a branch named “dev”:

ddev-live create site typo3 my-org/my-site --git-repo --git-rev dev

DDEV features automated deployments out of the box. The platform watches the Git revision you built the site from and rebuilds any time there is a change. If you’re already using a CI/CD solution in your workflow, DDEV can easily be added using our CLI and API (to automatically spin up QA environments, for example). One place where you don’t want automated deployments is production. When you’re ready to go live, all you need to do is create a tag in Git. You can deploy that tag to any non-production environment for a final test before switching your production site to that tag.

The freedom of flexibility

With specific references to Git revisions you can be very granular about what gets promoted to production or staging and be creative with workflows and automation. You might have a DDEV-Live environment pointed at your production code in a “1.19.0” tag, a CI/CD tool scripted to spin up test instances for automated testing from a “QA” branch, and an on-demand instance to work with that one commit from last month. 

Directly referencing and connecting to a central Git repository throughout your workflow gives you efficiency, cohesion and safety. Out of the box automation and the freedom to choose exactly what and how you want to deploy gives you flexibility to work the way you want to, the way your project and clients will benefit the most.

What’s next?

A sneak peek into the future! 

Currently, you could have work from a “qa” branch of your project in a DDEV-Live environment and share that work to anyone in the world from a preview URL. Next, DDEV is introducing more explicit support for temporary “preview sites” which are tied to pull or merge requests. 

In the near future, your DDEV workspace could have published, and ephemeral preview sites held in it referencing various stages of the project. For example: The published site is a reference to the “1.19.0” tag in your repository, and has DNS set up and is live online. A site built from your “qa” branch also exists. This branch is not published, but there is a PR against it with some changes. This PR can be used to quickly build a preview site by adding a comment to the PR. The preview site can then be shared via URL to stakeholders, and will be deleted when the PR is closed.

We’re very curious about how you’ll use some of these newer features and would love to chat with you about it. Drop a line in the contact form and we’ll get you rolling!

Share this post: