As I mentioned in my last post, my project is using OpenShift, and so far, we love it. Another tool we’re using is Snap-CI, which has incredibly seamless deployments to Heroku and AWS.
Deploying to OpenShift was pretty simple as well. We created a build stage in Snap-CI and added some tasks to the new stage:
By default OpenShift creates a copy of your existing Git repository. Each push to the new OpenShift repository triggers a deploy. In theory, this means that all we need to do is force a push to the OpenShift repository every time we want to deploy:
$ git push -f myopenshift.git
However, access to OpenShift is via SSH, which means that pushing looks more like this:
$ git push -f ssh://myopenshift.git
And which also means that Snap needs to know about our SSH key. In order to have our SSH key present when pushing, we first created an environment variable in Snap called OPENSHIFT_SSH, which we echoed to a file in the repository:
$ echo "$OPENSHIFT_SSH" > ./ssh_pk_file $ chmod 600 ssh_pk_file
We also had to change the permissions of the private key file.
Finally, we had a script that allowed us to specify the SSH key to use for pushing to OpenShift:
$ ./script/my_git.sh -i ssh_pk_file push -f ssh://myopenshift.git
We based our script off the one found here. All it does is take in a git command with a parameter (-i) that allows you to specify which SSH key you’d like to use.
Our final list of tasks to execute for our integration build step looks like this:
$ echo "$OPENSHIFT_SSH" > ./ssh_pk_file $ chmod 600 ssh_pk_file $ ./script/my_git.sh -i ssh_pk_file push -f ssh://myopenshift.git
Right now we have every push to our project git repository deploying to our integration environment via Snap. When we choose, we can then deploy to production, using the same steps as above.