WARNING: This project is no longer maintained. See ftw.deploy! |
---|
git-deploy allows to do deployment directly from git by pushing to the deployment remote. This tutorial shows how to use this with Plone.
For being able to use git-deploy
as described here, your deployment should
meet some prerequisits:
- You should have a git-repository with a policy and with buildout configurations.
- The policy is not distributed to index server (like pypi) but used directly from source.
- Using ftw-buildouts'
production.cfg
as buildout configuration base is recommended. - Using ftw.upgrade (>=1.14.0) is required for automatically updating the Plone site.
First, deployment scripts need to be added to the repository.
git-deploy
has a command for doing, but it is optimized for Rails apps.
For Plone, the scripts can simply be downloaded like this:
$ cd the-package-repository
$ mkdir deploy
$ cd deploy
$ wget https://raw.githubusercontent.com/4teamwork/plone-git-deployment/master/deploy/after_push
$ chmod +x after_push
$ wget https://raw.githubusercontent.com/4teamwork/plone-git-deployment/master/deploy/update_plone
$ chmod +x update_plone
The directories tmp
and log
most exist in the root:
$ cd the-package-repository
$ ln -s var/log
$ mkdir tmp
$ cd tmp
$ echo "*" > .gitignore
$ echo "!.gitignore" >> .gitignore
The notify_errbit
script notifies errbit about a deployment.
For this to work, there must be a bin/instance0
having these environment
variables declared:
ERRBIT_URL
ERRBIT_API_KEY
ERRBIT_APP_ID
(be aware thaterrbit-python
does not need this)ERRBIT_ENVIRONMENT
Installation:
$ cd the-package-repository
$ mkdir deploy
$ cd deploy
$ wget https://raw.githubusercontent.com/4teamwork/plone-git-deployment/master/deploy/notify_errbit
$ chmod +x notify_errbit
For beeing able to push directly to the deployment checkout later,
we need to add one remote per deployment.
Since everybody who will deploy has to do this, it is recommended to
add a script setting it up, e.g. a scripts/setup-git-remotes
:
#!/usr/bin/env bash
setup_remote () {
name=$1
url=$2
echo ""
echo "setup remote \"$name\" -> $url"
git remote rm $name 2> /dev/null
git remote add $name $url
git fetch $name
}
setup_remote "production" "[email protected]:/home/zope/02-plone-my.website.ch-PRODUCTION"
setup_remote "testing" "[email protected]:/home/zope/02-plone-my.website.ch-TESTING"
$ chmod +x scripts/setup-git-remotes
$ cd the-package-repository
$ ./scripts/setup-git-remotes
In order to set up the GIT hooks you need to install git-deploy
locally.
The setup is done only once, so not everybody has to install git-deploy.
The deployment should already exist and buildout should have ran once.
$ gem install git-deploy
$ cd the-package-repository
$ git deploy setup -r "testing"
$ git push testing master
Now deployments can be done from the local checkout by everybody with access to
the server (without installing git-deploy
):
$ cd the-package-repository
$ ./scripts/setup-git-remotes
$ git push testing master
When the deployment is in a VPN without SSH access, we cannot push to the
deployment.
In this situation the deploy/pull
script can be used for simulating a push.
It pulls from the upstream (the branch must have an upstream defined) and runs
the deployment scripts.
The deploy/after_push
script can be configured to run another script
than deploy/update_plone
.
For example you could add a scripts/nightly-reinstall
and then add to
your nightly buildout configuration file:
[buildout]
deployment-update-plone-script = scripts/nightly-reinstall
Be aware that this must be in the buildout.cfg
of the deployment (which
may be a symlink), but it can not be extended since the buildout config file
is not parsed recursively for this option.
When upgrades need to be installed, the script normally takes the site offline in order to prevent conflicting writes to the database while the upgrades run.
When having a zero downtime environment, such as when only a publihser writes the database (which is stopped while running upgrades), it is safe to keep the site running for anonymous users.
In order to enable this behavior you must set the deployment-zero-downtime
option in the buildout configurations which should be upgraded in zero downtime
mode.
WARNING: The deployment-zero-downtime
must be in the buildout.cfg
file
of the deployment. It does not work when using extend
for this option since
the option is directly read from buildout.cfg
.
Example::
[buildout]
extends =
...
deployment-zero-downtime = true
Deploy one commit with zero downtime
When deploying a commit with upgrade steps, the site will be taken offline
unless zero downtime is configured.
But sometimes we want to deploy a commit with (fast) upgrades to a
non-zero-downtime deployment, but without downtime.
For marking a commit as "zero-downtime proof", you can push it to the branch
zero-downtime
on the deployment remote, before doing a regular deployment.
Example:
$ git push testing master:zero-downtime
$ git push testing master
Activate zero downtime by environment variable When using deploy/pull, we can activate the zero downtime strategy with an environment variable:
Example:
$ ZERO_DOWNTIME=true deploy/pull