一千萬個為什麽

搜索

如何為每個拉取請求自動創建一個子域



背景

我得到了一個非技術QA團隊,他們必須針對由我的後端團隊創建的每個Pull Request(PR)在iOS/Android應用上進行測試。

這就是我想要做的:每當後端工程師在bitbucket上創建一個PR時,我希望腳本自動將該PR git分支的代碼部署到我們的開發服務器的子域中,該子域與創建的JIRA問題相匹配。

例如,假設jira問題是PR地址是BAC-421,那麽只要工程師創建PR,腳本就會將他們創建的代碼部署到AWS EC2中,以便QA可以將其應用程序指向www.bac421.mydevdomain。 COM

做這個的最好方式是什麽?我是一個devops技術人員。

更新 - 環境規格

所以這裏是我們env的分手 - 後端使用laravel 5.3 - 它部署在AWS EC2上 - 我們使用偽造進行自動部署(沒什麽奇怪的......我們只是運行這個腳本:

cd /home/forge/default
git fetch --tags 
git pull origin master
git describe
composer install --no-dev --no-interaction --prefer-dist --optimize-autoloader
echo "" | sudo -S service php7.1-fpm reload

if [ -f artisan ]
then
    PHP artisan migrate --force
    PHP artisan config:cache
    PHP artisan queue:restart
fi

我們一旦把我們合並為主分支,我們就跑了) - 除此之外,我們不使用任何CI/CD工具,盡管我願意提供建議 - DNS提供商是GoDaddy - 我們的應用服務器是nginx - 我們的數據庫在一個單獨的RDS實例中

轉載註明原文: 如何為每個拉取請求自動創建一個子域

一共有 1 個回答:

我們在工作中這樣做。

我們有一個小型服務器,我們稱之為接收器,它是 GitHub webhook事件的目標。它運行一個小型應用程序來分析有效載荷,並包含有關如何繼續操作的邏輯。在基礎設施提供商上創建一個新服務器,更新負載均衡器,部署到現有服務器,銷毀服務器等。這可能是一個傳統的Web應用程序提供API或它可能是無服務器的應用程序,由您決定接近它。

接收器相對比較簡單,您需要的其他必要支持系統是配置管理/配置(服務器如何運行應用程序所需的軟件包),秘密管理(服務器如何訪問敏感信息)和路由(子域如何更新並路由到正確的服務器)。

看看準備一個 AMI 是值得的。配置必要的服務,使用基礎架構配置邏輯的 CloudFormation 模板和 CodeDeploy 可以為您處理部署。

配置管理

這真的取決於你和你的團隊,有很多你可以使用的工具,或者你可以簡單地依賴shell腳本。在服務器生命周期的哪一點,您應用這些更改是AMI設計中討論的內容文章我鏈接。

秘密管理

這是一個具有挑戰性的話題來處理手頭的信息,為了簡潔起見,我會留給你和你的團隊。

路由</強>

有幾種方法可以處理路由,AWS提供的Application Load Balancer(不要與ELB/NLB混淆)支持 host based routing 。或者,您可以使用反向代理(如NGINX或HAProxy),當您提供新環境時,無論采取何種方法,您都需要更新此路由(理想情況下會自動)。

Don't forget to consider how you'll handle the database/persistence layer & zero down time deployments. The question to ask with the persistence layer is whether the team will share a database and how that will interact with things like migrations. On the topic of zero downtime deployments, CodeDeploy should handle that nicely for you. One more thing, you mentioned a single mobile application pointing to different environments, how will you point these applications to the environments.