usage:
gbdt [-v] <env> init - initialize environment with CURRENT(!) state
gbdt [-v] <env> deploy <tag> - deploys tagged state to environment
gbdt [-v] <env> status - show status of an environment
gbdt [-v] <env> tags - show available <tags> in an environment
gbdt [-v] stage deploy - deploys CURRENT state to staging
gbdt [-v] stage stop - remove staging environment
gbdt [-v] status - show status of all environments
<env> is an environment, see below
<tag> is a git tag
environments:
prod - production
stage - staging
I wanted to develop a static website with a separate staging and production environment. I sketched out a crude workflow for the webpage development:
- develop locally
- deploy to staging
- get feedback and review based on the staging version
- either go back to development or deploy the staging version to production
As I work on different machines, I needed some kind of source management. As I already do everything with it, git was the way to go. As I did not find a suitable existing tool after 5 minutes of searching, I went into "roll your own" mode and gbdt was born to support the workflow shown above. Being more of an infrastructure script, gbdt will propably also work for other things than just websites.
-
Initialize a git repository containg the website (e.g. the full webroot with the initial
index.html
as well as all needed subfolders). The production and staging environment access the same branch in the repository, normallymaster
. -
Create
~/.gbdt
containing the following: (look out, the file gets sourced, so don't put anything likerm -rf
in it!)-
GIT_REPO
- the git repository to use, e.g.ssh://somehost/home/foo/git/website.git
-
PRODUCTION_DIR
- the directory where the production environment should be checked out, e.g./var/www
-
STAGING_DIR
- the directory where the staging environment should be checked out, e.g./var/www/staging
(yes, I simply use a subdirectory on the normal production server - after testing I can stop the staging environment) -
GIT_BRANCH
(optional) - the branch to use for the checkouts to both environments (default if unset ismaster
) -
TAG_REGEXP
(optional) - an extended regular expression that filters the tags shown ongbdt tags
and prevents any tags not matching to be deployed to production (deployment to staging is still possible) (default if unset is.
, matching everything) -
post_deploy()
(optional) - a shell function to be run after every deployment, see below
-
-
Initialize the production environment with
gbdt prod init
-
To update production, run
gbdt prod deploy <tag>
, where<tag>
is a git tag from repository. Deployments to production need a tag so you can't just deploy arbitrary intermediate states of development (in fact, you can propably trick gbdt into deploying anything that looks like a git ref, e.g. a commit hash, but then that's your problem). -
Likewise, to deploy a tagged version to staging, use
gbdt stage deploy <tag>
. Unlike production, staging can also be pointed to the most current development version withgbdt stage deploy
. -
After a review, the staging checkout can be thrown away with
gbdt stage stop
. This is very useful for me, as the staging tree is located inside my production webroot and I don't want the staging version accessible for everyone at all times.
To run an arbitrary deployment script, define the post_deploy()
shell function in your configuration file like this:
# post-deployment hook
# $1: target_dir
# $2: environment_name
post_deploy()
{
# disable Apache access to the .git subdirectory
cd "$1"
chmod 700 .git
}
You could also write logfiles, ping Feedburner for an update or send an email. Sky's the limit!
gbdt was specifically designed to support my workflow. Both the workflow and gbdt have been conceived in just about 24 hours. Regarding the proposed workflow gbdt is already feature complete, so no immediate changes are planned. Whether my workflow will hold up to the needs of reality, only time will tell :-) If it does not work out, gbdt will propably evolve.
- support branch switching for staging
- As a developer I want to switch branches in the staging environment so I can showcase different features.
- but is it really needed? trying to live without it for now
- switch to getopt option parsing
- document all options (
-vv
and-v -v
currently missing) - provide -c option to select different configuration files
- document all options (
- remove init command
- deploy command could initialize automatically
- this would also prevent initializing production without a proper tag
The project is hosted at https://github.com/mmitch/gbdt
Copyright (C) 2015, 2016, 2018 Christian Garbs mitch@cgarbs.de
Licensed under GNU GPL v3 or later.
gbdt is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
gbdt is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with gbdt. If not, see http://www.gnu.org/licenses/.