patternMinor
Deploy to server after merge to master branch
Viewed 0 times
aftermergedeploymasterserverbranch
Problem
I currently have continuous deployment set up with a Travis CI job. All pushes are sent to the staging server and merges to the master to the production server. The problem is that the deployment to the production server is done before the merge is accepted. The continuous integration tests have to all pass, but the deployment occurs before manual code review is done.
The question is, what is a lightweight method to ensure that a deployment to the production server only takes place after the merge request has been accepted?
As a reference, the following code is used for deployment:
The question is, what is a lightweight method to ensure that a deployment to the production server only takes place after the merge request has been accepted?
As a reference, the following code is used for deployment:
#!/bin/bash
# exit with nonzero exit code if anything fails
set -e
# Add the SSH login key
chmod 600 veleda-deploy-key
mv veleda-deploy-key ~/.ssh/id_rsa
# Register the Veleda staging and production server SSH keys
echo '|1|BqdQKtUnA/AtCT/p2M7wgMq3wlY=|lH39cRtAE64wd6EG3ry2J9ewXic= ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBH3antqwy3D4NVVfHQX3SQc/g4wl/SAVC9w9QEry7hhQmB0SJIprwNAq8Hy2DzVCS7kTj/q7fCiiL7oAznrax+0=' >> $HOME/.ssh/known_hosts
echo '|1|+Z7oOsZ+zdL6u8o8VSWp+bRzd2g=|XMw2HyJIHoekOYlJYw1n75plL2E= ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBCJ/fa/mr577/qCuRXqUNccfmhpUtmi46LSyE7nDbOgxv8kZFs7yQ/sh6TM5npR+ZIbe9I0qmdvA+cE1QfvN21E=' >> $HOME/.ssh/known_hosts
# Select the remote to push to depending on the branch
if [ $TRAVIS_BRANCH != 'production' ] ; then
echo "Pushing to staging"
export REMOTE=staging.veleda.io
else
echo "Pushing to production"
export REMOTE=veleda.io
fi
# Push to the remote server
git remote add deploy "deploy@$REMOTE:/home/deploy/repo/"
git push -f deploy $TRAVIS_BRANCH
# Unpack and update the Docker services
ssh -t deploy@"$REMOTE" "\
mkdir -p veleda &&
git --work-tree=./veleda --git-dir=./repo checkout -f $TRAVIS_BRANCH &&
cd veleda &&
./start.sh"Solution
One could use conditional builds https://docs.travis-ci.com/user/conditional-builds-stages-jobs/
If code is merged into master one could decide to deploy code to production, but I personally prefer a human intervention by a Product Owner.
or
At other projects I preferred to deploy only tags to enforce the git flow (tags should be created otherwise no deployment to production).
One could also try (I did not try it yet) whether the
https://github.com/030/ansible-firefox/blob/master/.travis.yml
Last remark: I would avoid creating such scripts (the ones you included in the question) as most CI tools contain condition checks.
If code is merged into master one could decide to deploy code to production, but I personally prefer a human intervention by a Product Owner.
jobs:
include:
if: branch = masteror
stages:
- name: deploy
# require the branch name to be master
if: branch = masterAt other projects I preferred to deploy only tags to enforce the git flow (tags should be created otherwise no deployment to production).
stages:
- name: deploy
# require the tag name to match a regular expression
if: tag =~ ^v1One could also try (I did not try it yet) whether the
if works in combination with script sections:https://github.com/030/ansible-firefox/blob/master/.travis.yml
Last remark: I would avoid creating such scripts (the ones you included in the question) as most CI tools contain condition checks.
Code Snippets
jobs:
include:
if: branch = masterstages:
- name: deploy
# require the branch name to be master
if: branch = masterstages:
- name: deploy
# require the tag name to match a regular expression
if: tag =~ ^v1Context
StackExchange DevOps Q#3648, answer score: 4
Revisions (0)
No revisions yet.