Modern Web Deployment Workflow
27 |
This collection of Ansible playbooks have been designed to simplify deployment 30 | of a modern website or web app using Vagrant, Ubuntu, nginx and HTTP/HTTPS. Many 31 | tasks have been separated into separate roles, and as much configuration as 32 | possible has been abstracted into external variables.
33 |Deprecation Warning This project is no longer 34 | maintained. Bocoup discourages new projects from adopting these patterns and 35 | offers the original documentation (below) strictly as a resource for legacy 36 | projects.
37 |High-level benefits include:
38 |-
39 |
- A new server can be up and running with fully deployed code in just a few 40 | minutes. 41 |
- An update to an existing project can be deployed and built in under a minute. 42 |
- A project can be rolled back to a previously-deployed version in a matter of 43 | seconds. 44 |
- Updates to server configuration can be made in a matter of seconds. 45 |
- Most server configuration and code updates can be made with zero server 46 | downtime. 47 |
- Code can be tested locally in Vagrant before being deployed to a production 48 | server. 49 |
- Code can be tested on a staging server for QA or final testing before being 50 | deployed to a production server. 51 |
- Server configuration and project deployment can be made to scale to any number 52 | of remote hosts. 53 |
More specific benefits include:
55 |-
56 |
- Almost all server configuration and project deployment information is stored 57 | in the project, making it easy to destroy and re-create servers with 58 | confidence. 59 |
- All project maintainer user account information is stored in the project, 60 | making it easy to add or remove project maintainers. 61 |
- SSH agent forwarding allows the remote server to access private GitHub repos 62 | without requiring a private key to be copied to the server or for dedicated 63 | deployment keys to be configured. 64 |
- While working locally, the Vagrant box can easily be toggled between 65 | development and deployment modes at any time. This allows local changes to be 66 | previewed instantly (development) or a specific commit to be built as it would 67 | be in production (deployment). 68 |
- SSL certs can be auto-generated for testing HTTPS in development. 69 |
- Because the entire deployment workflow is comprised of Ansible playbooks and a 70 | Vagrantfile, it can be easily modified to meet any project's needs. 71 |
Here are links to the official, original project home page, documentation, Git 73 | repository and wiki:
74 |-
75 |
- Canonical home page & documentation 76 |
- Canonical Git repository 77 |
- Canonical wiki 78 |
Notes:
80 |-
81 |
- Even though Node.js and npm are used in this sample project, with minor 82 | edits this workflow can be made to work with basically any programming 83 | language, package manager, etc. 84 |
- This workflow won't teach you how to create an AWS instance. Fortunately, 85 | there are already excellent guides for creating a key 86 | pair, 87 | setting up a security 88 | group 89 | and launching an 90 | instance. 91 |
- This workflow has been thoroughly tested in Ubuntu 14.04 LTS
92 | (trusty). More specifically, with the
93 | ubuntu/trusty64 Vagrant
94 | image and with the AWS EC2
Ubuntu Server 14.04 LTSAMI. Minor adjustments 95 | might need to be made for other providers, while more substantial changes 96 | might need to be made for other Ubuntu versions or Linux distributions.
97 | - While this workflow has been designed to meet the needs of a typical use 98 | case, it might not meet your project's needs exactly. Consider this to be 99 | a starting point; you're encouraged to edit the included playbooks and roles! 100 |
Overview
102 |Assuming you've already created (or are in the process of creating) a website or 103 | web app, you will typically perform these steps when using this workflow.
104 |-
105 |
- Ensure the workflow dependencies have been installed on your 106 | development machine. 107 |
- Add and commit the workflow files into your project. 108 |
- Modify the Ansible variables, playbooks and roles to meet your 109 | specific project needs. 110 |
- Test your project on the local Vagrant box while authoring 111 | it. (Optional, but recommended) 112 |
- Deploy your project to a staging server for QA and final 113 | testing. (Optional, but recommended) 114 |
- Deploy your project to a production server. 115 |
Step 1 is usually only done per development machine, steps 2-3 are usually only 117 | done per project, and steps 4-6 will be repeated throughout the life of your 118 | project as you make and test changes and deploy new versions of your website or 119 | web app.
120 |Dependencies
121 |The following will need to be installed on your local development machine before 122 | you can use this workflow. All versions should be the latest available unless 123 | otherwise specified.
124 |-
125 |
- Ansible (version 2.1.x)
-
126 |
- Install
ansiblevia apt (Ubuntu), yum (Fedora), homebrew (OS 127 | X), etc. See the Ansible installation 128 | instructions for detailed, 129 | platform-specific information.
130 |
132 | - Install
- VirtualBox
-
133 |
- Download (All platforms) 134 |
- Install
virtualboxvia homebrew cask (OS X)
135 |
137 | - Vagrant
-
138 |
- Download (All platforms) 139 |
- Install
vagrantvia homebrew cask (OS X)
140 |
142 | - vagrant-hostsupdater
-
143 |
- Install with
vagrant plugin install vagrant-hostsupdater(All platforms)
144 |
146 | - Install with
Notes:
148 |-
149 |
- Ansible doesn't really work in Windows. But it works great in OS X and Linux, 150 | so be sure to use one of those operating systems for development. 151 |
Initial Setup
153 |Copy this project's files so that the deploy directory is in the root of 154 | your project Git repository. Be sure to copy recursively and preserve file 155 | modes, eg. executable, so that the bash helper script 156 | continues to work. The Vagrantfile and 157 | ansible.cfg file should be placed in your project root 158 | directory, not the deploy directory.
159 |Also, be sure to add .vagrant to your project's .gitignore file so that
160 | directory's contents, which are auto-generated by Vagrant, aren't committed with
161 | your project's source.
Ansible
163 |At the core of this workflow is Ansible, an IT automation tool. Ansible aims to 164 | be simple to configure and easy to use, while being secure and reliable. In this 165 | workflow, Ansible is used to configure systems and deploy software.
166 |Ansible Configuration
167 |Ansible Variables
168 |Much of this workflow's behavior can be configured via Ansible variables.
169 |-
170 |
- deploy/ansible/group_vars/all.yml - variables global to all 171 | playbooks and roles 172 |
Host-specific settings may be defined in host-named files in the 174 | host_vars directory and will override global values.
175 |-
176 |
- deploy/ansible/host_vars/vagrant - variables specific to the
177 |
vagrantinventory host
178 |
Variables may be overridden when a playbook is run via the --extra-vars
180 | command line option. These variables are noted in the preceding files as EXTRA
181 | VARS.
See the Ansible variables
183 | documentation for more information on variables, variable precedence, and how
184 | {{ }} templates and filters work.
Ansible Inventory
186 |These files contain the addresses of any servers to which this project will be 187 | deployed. Usually, these addresses will be fully qualified domain 188 | names, but they may 189 | also be IPs. Each inventory file may contain a list of multiple server FQDNs or 190 | IPs, allowing a playbook to be deployed to multiple servers simultaneously, but 191 | for this workflow, each inventory file will list a single server.
192 |-
193 |
- deploy/ansible/inventory/production 194 |
- deploy/ansible/inventory/staging 195 |
- deploy/ansible/inventory/vagrant 196 |
Like with host variables, settings defined here will
198 | override those defined in the global variables and group
199 | variables files. For example, in the staging inventory, the
200 | site_fqdn variable can be set to the staging server's FQDN, allowing nginx to
201 | respond to requests made to its FQDN instead of the production server's FQDN.
Unless the variable is a server name-specific override like site_fqdn or
203 | ansible_ssh_host, it should probably be defined in host
204 | variables.
Ansible Playbooks
206 |Ansible playbooks are human-readable documents that describe and configure the 207 | tasks that Ansible will run on a remote server. They should be idempotent, 208 | allowing them to be run multiple times with the same result each time.
209 |The following playbooks are included in this workflow:
210 |-
211 |
- provision playbook 212 |
- configure playbook 213 |
- deploy playbook 214 |
- vagrant-link playbook 215 |
- init playbook 216 |
For more detailed information on what each playbook actually does and how it 218 | will need to be configured, be sure to check out the description for each 219 | role that playbook includes.
220 |provision playbook
221 |Provision server. This playbook must be run when a server is first created 222 | and is typically only run once. It may be run again if you make server-level 223 | changes or need to update any installed apt modules to their latest versions. 224 | If you were creating a new AMI or base box, you'd do so after running only 225 | this playbook.
226 |-
227 |
- Playbook: deploy/ansible/provision.yml 228 |
- Roles: base 229 |
configure playbook
231 |Configure server. This playbook is run after a server is provisioned but 232 | before a project is deployed, to configure the system, add user accounts, 233 | and setup long-running processes like nginx, postgres, etc.
234 |-
235 |
- Playbook: deploy/ansible/configure.yml 236 |
- Roles: configure, users, nginx 237 |
deploy playbook
239 |Clone, build, and deploy, restarting nginx if necessary. This playbook must
240 | be run after provision and configure, and is used to deploy and build the
241 | specified commit (overridable via extra vars) on the server. Running this
242 | playbook in Vagrant will override the vagrant-link playbook, and vice-versa.
-
244 |
- Playbook: deploy/ansible/deploy.yml 245 |
- Roles: deploy 246 |
vagrant-link playbook
248 |Instead of cloning the Git repo and building like the deploy playbook, this
249 | playbook links your local working project directory into the Vagrant box so that
250 | you can instantly preview your local changes on the server, for convenience
251 | while developing. While in this mode, all building will have to be done
252 | manually, at the command line of your development machine. Running this playbook
253 | will override the deploy playbook, and vice-versa.
-
255 |
- Playbook: deploy/ansible/vagrant-link.yml 256 |
init playbook
258 |This playbook saves the trouble of running the provision, configure and
259 | vagrant-link playbooks individually, and is provided for convenience. After
260 | vagrant up, this playbook will be run on the new Vagrant box.
-
262 |
- Playbook: deploy/ansible/init.yml 263 |
Ansible Roles
265 |There are multiple ways to organize playbooks, and while it's possible to put 266 | all your tasks into a single playbook, it's often beneficial to separate related 267 | tasks into "roles" that can be included in one or more playbooks, for easy reuse 268 | and organization.
269 |The following roles are used by this workflow's playbooks:
270 |-
271 |
- base role 272 |
- configure role 273 |
- nginx role 274 |
- users role 275 |
- deploy role 276 |
base role
278 |Get the box up and running. These tasks run before the box is configured 279 | or the project is cloned or built. All system dependencies should be 280 | installed here.
281 |Apt keys, apt ppas, apt packages and global npm modules can be configured in the
282 | PROVISIONING section of the global variables file. If
283 | you need custom packages or modules to be installed, specify them there.
Don't be afraid to modify these tasks. For example, if your project doesn't use 285 | npm, just remove the npm tasks.
286 |This role contains the following files and tasks:
287 |-
288 |
- main.yml
-
289 |
- ensure apt cache is updated 290 |
- ensure all packages are upgraded safely 291 |
- add keys to apt 292 |
- add ppas to apt 293 |
- install apt packages 294 |
- update npm to latest 295 |
297 |
(Browse the deploy/ansible/roles/base directory for more information)
299 |configure role
300 |Configure the box. This happens after the base initialization, but before 301 | the project is cloned or built.
302 |This role contains the following files and tasks:
303 |-
304 |
- swap.yml
-
305 |
- check if swap file exists 306 |
- ensure swapfile exists 307 |
- ensure swap file has correct permissions 308 |
- ensure swapfile is formatted 309 |
- ensure swap file can be mounted 310 |
- ensure swap is activited 311 |
- ensure swap is used as a last resort 312 |
314 | - main.yml
-
315 |
- set hostname 316 |
- ensure unattended upgrades are running 317 |
- add loopback references to our domain in /etc/hosts 318 |
- disallow password authentication 319 |
- disallow challenge response authentication 320 |
- ensure github.com is a known host 321 |
- ensure ssh agent socket environment variable persists when sudoing 322 |
- allow passwordless sudo - development only! 323 |
325 |
(Browse the deploy/ansible/roles/configure directory for more information)
327 |nginx role
328 |Generate nginx config files (and ssl configuration, if ssl was specified), 329 | rolling back changes if any part of the config is invalid.
330 |The public site path, ssl and ssl cert/key file locations can be configured in
331 | the WEB SERVER section of the global variables file. If
332 | you want to override any settings for just Vagrant, you can do so in host
333 | variables.
By default, nginx is configured to serve a website with a custom 404 page.
335 | However, if you want to redirect all requests to index.html (eg. for a web
336 | app), you should modify the site.conf
337 | template per the inline comments. For more involved customization, read the
338 | nginx documentation.
If you enable SSL for production or staging, you will need to supply your
340 | own signed SSL cert/key files and put them on the remote server via AWS
341 | CloudFormation,
342 | cloud-init, or you can copy them
343 | manually
344 | before provisioning, or this role will fail.
If you choose to enable SSL for vagrant, self-signed SSL cert/key files will
346 | be generated for you automatically if they don't already exist. In this case,
347 | your website or web app will work, but you will have to click past a SSL
348 | certificate warning before viewing it.
This role contains the following files and tasks:
350 |-
351 |
- ssl.yml
-
352 |
- generate strong dhe parameter 353 |
- create self-signed ssl cert/key 354 |
- ensure ssl cert/key exist 355 |
357 | - main.yml
-
358 |
- ensure default nginx server is not present 359 |
- ensure nginx config files exist 360 |
- backup existing nginx config files 361 |
- generate new nginx config files 362 |
- ensure nginx config is valid 363 |
- remove temporary backups if new nginx config files are valid 364 |
- restore temporary backups if new nginx config files are invalid 365 |
367 | - certbot.yml
-
368 |
- add certbot ppa to apt 369 |
- install certbot 370 |
- ensure certbot well-known path exists 371 |
- test if certbot has been initialized 372 |
- ensure any pending nginx reload happens immediately 373 |
- intialize certbot 374 |
- ensure certbot certs are linked 375 |
- Add cron job for cert renewal 376 |
378 |
And the following templates:
380 |-
381 |
- gzip_params 382 |
- site.conf 383 |
- ssl_params 384 |
(Browse the deploy/ansible/roles/nginx directory for more information)
386 |users role
387 |In development (localuser.yml), 388 | create an account for the currently logged-in user, and copy their public key to 389 | the server. This makes it possible to run other playbooks without specifying a 390 | user or private key on the command line.
391 |In production (users.yml), ensure all
392 | users have been added, along with any public keys. If any user's state is
393 | absent, they will be removed. If any keys are removed, they will be deleted.
394 | In a development environment, make sudo passwordless, for convenience.
User accounts, passwords and public keys can be configured in the USERS
396 | section of the global variables file.
This role contains the following files and tasks:
398 |-
399 |
- users.yml
-
400 |
- ensure users are synced 401 |
- ensure user public keys are synced 402 |
404 | - main.yml 405 |
- localuser.yml
-
406 |
- ensure local user is synced 407 |
- ensure the local user's public key is synced 408 |
410 |
(Browse the deploy/ansible/roles/users directory for more information)
412 |deploy role
413 |Clone the repo and check out the specified commit unless it has already been 414 | checked out. When done, symlink the specified commit to make it go live, and 415 | remove old clones to free up disk space.
416 |The Git repo URL, deployment paths, number of recent deployments to retain and
417 | build info file path can be configured in the DEPLOY section of the
418 | global variables file.
The following variables defined in the DEPLOY EXTRA VARS section of the same
420 | file may be overridden on the ansible-playbook command line in the format
421 | --extra-vars="commit=mybranch force=true".
| var | 426 |default | 427 |description | 428 |
|---|---|---|
remote |
433 | bocoup |
434 | Specify any remote (typically a github user). | 435 |
commit |
438 | master |
439 | Specify any ref (eg. branch, tag, SHA) to be deployed. This ref must be pushed to the remote git_repo before it can be deployed. |
440 |
force |
443 | false |
444 | Clone and build the specified commit SHA, regardless of prior build status. | 445 |
local |
448 | false |
449 | Use the local project Git repo instead of the remote git_repo. This option only works with the vagrant inventory, and not with staging or production. |
450 |
The build.yml file contains all the
454 | build tasks that need to be run after your project is cloned, eg. npm install,
455 | npm run build. Don't be afraid to modify these tasks. Your project's build
456 | process might need to be different than what's here, so adjust accordingly!
This role contains the following files and tasks:
458 |-
459 |
- main.yml 465 | 466 |
- checkout.yml
-
467 |
- ensure pre-existing temp directory is removed 468 |
- clone git repo into temp directory 469 |
- get sha of cloned repo 470 |
- check if specified commit sha has already been deployed 471 |
- delete pre-existing sha-named directory 472 |
- move cloned repo to sha-named directory 473 |
- ensure just-created temp directory is removed 474 |
476 | - build.yml
-
477 |
- compare package.json of current deploy with previous deploy 478 |
- copy existing npm modules 479 |
- install npm modules 480 |
- build production version 481 |
- generate build info file 482 |
484 |
And the following templates:
486 |-
487 |
- build_info.txt 488 |
(Browse the deploy/ansible/roles/deploy directory for more information)
490 |Vagrant
491 |Vagrant allows you to isolate project dependencies (like nginx or postgres) in a 492 | stable, disposable, consistent work environment. In conjunction with Ansible and 493 | VirtualBox, Vagrant ensures that anyone on your team has access to their own 494 | private, pre-configured development server whenever they need it.
495 |If you only want to deploy to remote production or staging servers, you can just 496 | install Ansible and skip VirtualBox and Vagrant, which are only used to create 497 | the local development server.
498 |Configuring Vagrant
499 |The Vagrantfile file at the root of the repo contains the 500 | project's Vagrant configuration. Be sure to specify an appropriate hostname 501 | alias for the Vagrant box here.
502 |Using Vagrant
503 |Once the Vagrantfile and Ansible variables, playbooks
504 | and roles have been customized to meet your project's
505 | needs, you should be able to run vagrant up to create a local,
506 | fully-provisioned Vagrant server that is accessible in-browser via the hostname
507 | alias specified in the Vagrantfile. If you're asked for your administrator
508 | password during this process, it's so that the hostsupdater plugin can modify
509 | your /etc/hosts file.
If you change the Ansible configuration, running vagrant provision will re-run
511 | the Ansible playbooks. If you make drastic changes to the Ansible configuration
512 | and need to recreate the Vagrant server (which is often the case), you can
513 | delete it with vagrant destroy. If you do this, be sure to let collaborators
514 | know too!
See the Vagrant Ansible 516 | provisioner 517 | documentation for more information.
518 |Using SSH with Vagrant
519 |Vagrant provides the vagrant ssh command which allows you to connect to the
520 | Vagrant box via its built-in vagrant user. While this is convenient for some
521 | basic development tasks, once provisioned, you should connect to the Vagrant box
522 | using the user account created by the users role. This will
523 | ensure that the ansible-playbook command, which uses ssh
524 | internally, will work, allowing you to deploy.
To connect to Vagrant in this way, use the ssh command along with the
526 | hostname alias defined in the Vagrantfile. Eg, for this
527 | example project, the command would be ssh deployment-workflow.loc.
Also, adding a section like
529 | this
530 | to your ~/.ssh/config file will prevent SSH from storing Vagrant box keys in
531 | ~/.ssh/known_hosts and complaining about them not matching when a Vagrant
532 | box is destroyed and recreated. Do not do this for production servers. This is
533 | only safe for private, local virtual machines!
Deploying
535 |Once you've customized Ansible variables, playbooks and
536 | roles and committed your changes to the Git repository
537 | configured in global variables, you may run the
538 | ansible-playbook command or the included playbook helper
539 | script to run any playbook on
540 | any inventory host.
Command Line Flags
542 |Note that the following flags apply to both ansible-playbook and the included
543 | playbook helper script.
-
545 |
--help- Display usage information and all available options; the list 546 | here contains only the most relevant subset of all options.
547 | --user- Connect to the server with the specified user. If a user isn't 548 | specified, the currently logged-in user's username will be used.
549 | --ask-become-pass- If the remote user account requires a password to be 550 | entered, you will need to specify this option.
551 | --private-key- If the remote user account requires a private key, you 552 | will need to specify this option.
553 | --extra-vars- Values that override those stored in the ansible 554 | configuration in the format 555 |--extra-vars="commit=mybranch force=true".
556 | -vvvv- Display verbose connection debugging information.
557 |
Production and Staging Notes
559 |Once the users role has run successfully, assuming your user
560 | account has been correctly added to it, you should be able to omit the --user
561 | and --private-key command line flags. However, until the users role has run at
562 | least once:
-
564 |
- the
--userflag will need to be specified. For the default AWS EC2 Ubuntu 565 | AMI, use--user=ubuntu.
566 | - the
--private-keyflag will need to be specified. For AWS, specify 567 |--private-key=/path/to/keyfile.pemwherekeyfile.pemis the file 568 | downloaded when creating a new key 569 | pair 570 | in AWS. Do not store this private key in your project Git repo!
571 |
The default AWS ubuntu user doesn't require a password for sudo, but user
573 | accounts added via the users role do, so be sure to specify the
574 | --ask-become-pass flag when you omit the --user command line flag.
Vagrant Notes
576 |Once the users role has run successfully, assuming your user
577 | account has been correctly added to it, you should be able to omit the --user
578 | and --private-key command line flags. However, until the users role has run at
579 | least once:
-
581 |
- specify
--user=vagrant, which is the default user created for the Vagrant 582 | box.
583 | - specify
--private-key=.vagrant/machines/vagrant/virtualbox/private_key, 584 | which is where the private key file for uservagrantis generated during 585 |vagrant up.
586 |
Additionally, you should never need to use the --ask-become-pass flag in
588 | Vagrant, once passwordless sudo has been enabled via the configure
589 | role. This is done for convenience.
Playbook helper script
591 |While you may run the ansible-playbook command manually, the
592 | deploy/run-playbook.sh bash script has been provided to facilitate
593 | running ansible-playbook.
Usage: run-playbook.sh playbook[.yml] inventory [--flag ...] [var=value ...]
595 |
596 | playbook playbook file in deploy/ansible/, the .yml extension is optional.
597 | inventory inventory host file in deploy/ansible/inventory/.
598 | --flag any valid ansible-playbook flags, Eg. --help for help, -vvvv for
599 | connection debugging, --user=REMOTE_USER to specify the remote
600 | user, --ask-become-pass to prompt for a remote password, etc.
601 | var=value any number of ansible extra vars in the format var=value.
602 | Notes
603 |-
604 |
- Flags and vars must be specified after both
playbookandinventory.
605 | - All arguments specified after
playbookandinventorynot beginning with 606 |-or--will be treated as extra vars.
607 | - If a non-
vagrantinventory host is specified, unless theubuntuuser is 608 | specified, the--ask-become-passflag will be automatically added to the 609 | command.
610 | - You may pass flags to this scripts as you would to
ansible-playbook. Eg. 611 |--helpfor help,-vvvvfor connection debugging,--user=REMOTE_USERto 612 | specify the remote user,--ask-become-passto prompt for a remote account 613 | password, etc.
614 | - You may specify any number of extra variables at the end of the command in the
615 | format
foo=12 bar=34instead of the more verbose default 616 |--extra-vars="foo=12 bar=34".
617 |
Examples
619 |The following command to run the provision playbook on the
620 | production inventory host with the --user and --private-key command line
621 | flags:
-
623 |
ansible-playbook deploy/ansible/provision.yml 624 | --inventory=deploy/ansible/inventory/production --user=ubuntu 625 | --private-key=~/keyfile.pem
626 |
can be run like:
628 |-
629 |
./deploy/run-playbook.sh provision production --user=ubuntu 630 | --private-key=~/keyfile.pem
631 |
And the following command to run the deploy playbook on the vagrant
633 | inventory host with the commit and local extra variables:
-
635 |
ansible-playbook deploy/ansible/deploy.yml 636 | --inventory=deploy/ansible/inventory/vagrant --extra-vars="commit=testing 637 | local=true"
638 |
can be run like:
640 |-
641 |
./deploy/run-playbook.sh deploy vagrant commit=testing local=true
642 |
More Examples
644 |-
645 |
- Assume these examples are run from the root directory of your project's Git 646 | repository. 647 |
- Don't type in the
$, that's just there to simulate your shell prompt.
648 |
# Provision the production server using the ubuntu user and the ~/keyfile.pem
650 | # private key. Note that while this installs apt packages, it doesn't
651 | # configure the server or deploy the site.
652 |
653 | $ ./deploy/run-playbook.sh provision production --user=ubuntu --private-key=~/keyfile.pem
654 | # Run just the tasks from the nginx role from the configure playbook on the
656 | # production server. Using tags can save time when only tasks from a certain
657 | # role need to be re-run.
658 |
659 | $ ./deploy/run-playbook.sh configure production --tags=nginx
660 | # If the current commit at the HEAD of master was previously deployed, this
662 | # won't rebuild it. However, it will still be symlinked and made live, in case
663 | # a different commit was previously made live. If master has changed since it
664 | # was last deployed, and that commit hasn't yet been deployed, it will be
665 | # cloned and built before being symlinked and made live.
666 |
667 | $ ./deploy/run-playbook.sh deploy production
668 | # Like above, but instead of the HEAD of master, deploy the specified
670 | # branch/tag/sha.
671 |
672 | $ ./deploy/run-playbook.sh deploy production commit=my-feature
673 | $ ./deploy/run-playbook.sh deploy production commit=v1.0.0
674 | $ ./deploy/run-playbook.sh deploy production commit=8f93601a6bc7efeb90b1961d7574b47f61018b6f
675 | # Regardless of the prior deploy state of commit at the HEAD of the my-feature
677 | # branch, re-clone and rebuild it before symlinking it and making it live.
678 |
679 | $ ./deploy/run-playbook.sh deploy production commit=my-feature force=true
680 | # Deploy the specified branch to the Vagrant box from the local project Git
682 | # repo instead of the remote Git URL. This way, the specified commit can be
683 | # tested before being pushed to the remote Git repository.
684 |
685 | $ ./deploy/run-playbook.sh deploy vagrant commit=my-feature local=true
686 | # Link the local project directory into the Vagrant box, allowing local changes
688 | # to be previewed there immediately. This is run automatically at the end of
689 | # "vagrant up".
690 |
691 | $ ./deploy/run-playbook.sh vagrant-link vagrant
692 |