Read this guide first. Core dna is hosted, so there is nothing to install; your repository holds only templates and front-end assets; and a new kind of page starts in the admin, with a layout. In half a day, from what the platform is to a page you built, deployed and rendered in Smarty or Twig.
L0
Unit 02 · From zero to a deployed change
Deploying a change
From zero to a deployed changePage 13 of 28Updated
Deploying is pushing a branch. Every environment that follows that repository and branch makes its files match the branch and clears its caches. How branches map to environments, how to see what is deployed, and what to do when you push the wrong thing.
Who this is for. Anyone about to push to a site's repository for the first time. After this page you will know what a push does on the platform, which environment it reaches, and how to check it arrived.
A push is a deploy
You push a branch to the site's repository.
The repository host notifies the platform of the push.
Every environment that follows that repository and branch is updated: the platform fetches the branch and resets the environment's folder to it. Files tracked in the repository end up exactly as they are on the branch, deletions included. Files the repository does not track, such as settings files Core dna keeps on the server, are left alone.
The caches of every environment using that folder are cleared: the page cache, the compiled templates and the CDN's copies of static files.
There is no build step, review or approval anywhere in that sequence. Once the deploy has run, what you pushed is what the site serves.
Which branch goes where
Each environment follows at most one repository and branch, which Core dna sets up. A common mapping is master or main to production and a development or staging branch to the other environments, but it is chosen per site. Ask, and write the answer in the repository's README for the next person.
A push to a branch no environment follows deploys nothing. That is how feature branches stay safe to push.
A push to the production branch deploys to the live site at once.
The push to production is the release
Nothing stands between a push to the production branch and the live site. Merge to that branch only what is ready to go live, and only when you mean to release it.
Seeing what is deployed
In the page source. If the templates add the deployed commit to asset URLs, as most do, the ?v= value on the stylesheet is the first seven characters of the latest push the environment has logged. That push may still be running, or may have failed, so check its status in the deployment log before trusting it.
In the admin. Under System › Sites › Environments, each environment's Deployments column opens its deployment log: every push with its commit, branch, author, message and status (pending, running, success, skipped or failed). It is open to Super admin and Developer users only.
Development environments updated by upload
Some development environments are not deployed by push at all: the developer's editor uploads each file to the environment's folder as it is saved. There is then no deploy, no entry in the deployment log and no cache clearing; the server holds whatever was uploaded last, and switching branches locally can upload the switch. FTP and tracked files covers how that mixes with git.
When you push the wrong thing
To a branch no environment follows: nothing happened. Delete the branch if you like.
To the production branch: the change is live. Push a commit that reverses it rather than rewriting the branch's history: the next push deploys whatever the branch then holds, and a revert keeps everyone else's clones intact.
Shell
git revert <commit> # a new commit that undoes the bad one
git push origin master # the production branch, whatever this site calls it
A revert takes back files only. If the bad change came with admin work, a new layout or areas say, that stays as it is: a deploy never touches the database.