Deploying with other Integration Systems

Using other integration systems

In our preconfigured images, we use Capistrano as integration system, so our deploy script was written specially for Capistrano. But, it may easily be adapted to other systems.

First of all, you need to understand the meaning of the LOCAL_DIR variable from the script. This variable points to local copy of the repository tree. The script will check this path and clone/checkout your repository there if the folder identified by $LOCAL_DIR do not exist, otherwise it will perform an update. In the Capistrano case, it’s used as folder where Capistrano configuration file stands, but Capistrano will deploy to another folder, as specified in it’s configuration file. If your integration system doesn’t checkout sources by itself and it uses this folder as source to perform builds (for example, the C++ ant system), feel free to modify LOCAL_DIR*to point to a location you want.

Second, you need to adjust setup() method, you can set it empty, if there is no need to setup anything.

And last, build commands. The main command is specified in CMD_DEPLOY. If CMD_DEPLOY is exported (environment variable with this name exists) this value will be used, otherwise it will use hardcoded sequence (in our version of the script for Capistrano it is “cap deploy STAGE=1”). Other commands are specified with CMD_MIGRATE and CMD_CLEANUP, remove or update them according to your needs.

Customizing the Deploy Script.

Each time the deploy method of the webservice is invoked, it will run bin/deploy.sh script. There is one mandatory parameter, project name, and second, optional parameter, with values from [‘skip_no_commits’, ‘on_commit’]

• skip_no_commits – this parameter is specified when build is started automatically, not manually, so you can force manual builds, or skip automated builds if no new commits detected in repository.
• on_commit – this parameter indicates deploy was started automatically by commit event, so you can add some additional logic, by example, wait for some timeout and check again for new commits, if a commit detected start deploy, otherwise wait, and so on.

Also, for each configured project, in bin directory a special script, {project_name}_conf.sh, is stored. This script exports some project specific environment variables, and it is created/updated by configure action, when the user updates the Build Tool configuration.

List of exported environment variables:

• PROJECT_NAME – the name of the project
• SPACE_TOOL_ID – the id of the Build tool, usually you don’t need it
• SECRET_KEY – the tool secret key, like SPACE_TOOL_ID, you ususally don’t need it
• POST_URL – this url is used by webservice to post build results to space.
• SCM_URL – the repository url of the project
• SCM – SCM type, may be one of ‘svn’ or ‘git’
• SCM_LOGIN – the login name of the user that have read permissions in the repository.
• SCM_PASSWORD – the password of the user specified in SCM_LOGIN

The main thing about deploy script is it should return 0 if the build is successful, or 99 if the build is skipped (for example, if no new changes commited), and any other value if failed (usually 1). Other than that, you can modify/write the Deploy Script as you want, there are no rules except the rule about return value.