一千萬個為什麽

搜索

合並到主分支後部署到服務器



我目前使用Travis CI工作進行持續部署設置。所有推送都將發送到登臺服務器,並合並到主服務器到生產服務器。問題是在接受合並之前完成了對生產服務器的部署。持續集成測試必須全部通過,但部署在手動代碼審查完成之前進行。

問題是,什麽是一種輕量級方法,以確保僅在接受合並請求後才能對生產服務器進行部署?

作為參考,以下代碼用於部署:

#!/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 "[email protected]$REMOTE:/home/deploy/repo/"
git push -f deploy $TRAVIS_BRANCH

# Unpack and update the Docker services
ssh -t [email protected]"$REMOTE" "\
    mkdir -p veleda &&
    git --work-tree=./veleda --git-dir=./repo checkout -f $TRAVIS_BRANCH &&
    cd veleda &&
    ./start.sh"

轉載註明原文: 合並到主分支後部署到服務器

一共有 2 個回答:

One could use conditional builds https://docs.travis-ci.com/user/conditional-builds-stages-jobs/

如果代碼合並到master中,則可以決定將代碼部署到生產中,但我個人更喜歡產品所有者的人為幹預。

<�預> <�代碼>工作:   包括:       if:branch = master </代碼>

要麽

<�預> <�代碼>階段:    - 名稱:部署     #要求分支名稱為master     if:branch = master </代碼>

At other projects I preferred to deploy only tags to enf要麽ce the git flow (tags should be created otherwise no deployment to production).

<�預> <�代碼>階段:    - 名稱:部署     #要求標記名稱與正則表達式匹配     if:tag =〜^ v1 </代碼>

One could also try (I did not try it yet) whether the if w要麽ks in combination with script sections:

https://github.com/030/ansible-firefox/blob/master/.travis.yml

最後一點:我會避免創建這樣的腳本(問題中包含的腳本),因為大多數CI工具都包含條件檢查。

問題中更新的部署腳本支持以下工作流程(並且需要此服務器設置):

  1. Create a feature branch and push commits to it
  2. Each push deploys the code to the staging server
  3. Review the code with merge request (feature branch --> master)
  4. After merging to master, create a new merge request (master --> production)

由於Github合並請求勘誤,我在合並到master時進行了反轉,但在合並到生產時正常合並。這背後的原因是Github 創建新的提交(不同的SHA1 )當變基時。

GitHub上的rebase和merge行為與git略有不同   變基。 GitHub上的Rebase和merge將始終更新提交者   信息並創建新的提交SHA,而git rebase在。之外   在rebase時,GitHub不會更改提交者信息   發生在祖先提交之上。

該工作流程與030答案的主要區別在於使用生產分支而不是標簽。

For bonus points use staging SSL certificates from Let's Encrypt on your staging server. To enable it while using a reverse proxy in Docker, set LETSENCRYPT_TEST=true