Protected Branches機能で柔軟なワークフローを構築する
さて前回の記事では、GitHub Flowのごくごく基本的な部分についておさらいしてみました。基本ということで、CIやデプロイについては触れず、レビュー後にすぐマージする形でお話をしました。 GitHub社が実際に実施しているGitHub Flowにおいては、レビュー後にすぐマージするのではなく、マージ前に当該Pull Requestブランチを本番環境にデプロイするのが基本的な流れになります。もちろん、本番環境以外にも複数のテスト用環境が用意されており、場合によって複数のテスト環境で動作を確認してから本番環境へデプロイする場合も多くあります。また、デプロイフローは自動化されており、ブランチを本番環境にデプロイする前に、自動的にCIが実行され、コードが正しく動作するかがチェックされます。デプロイ後に本番環境にて問題なく動作することを確認後、masterブランチにマージします。逆に動作に不審な
CodeDeploy, S3 を併用して CircleCI により VPC にデプロイ
こんにちは。@jedipunkz です。 最近、業務で CircleCI を扱っていて、だいぶ “出来ること・出来ないこと” や “出来ないこと に対する回避方法” 等のノウハウが若干溜まってきたので共有したいなと思います。 この記事の前提… ここでは CodeDeploy の設定方法や、CircleCIの設定方法等に関しては記述しませ ん。あくまで、Tips 的な内容にしています。また運用する上で想定できる問題点と、 それの回避方法等…についてまとめています。 CirlceCI と併用するサービスについて CircleCI は Github と連携してレポジトリ内の制御ファイル circle.yml に従ってテ スト・ビルド・デプロイを実施してくれる CI サービスです。ただ CircleCI は自分た ちの管理しているシステム外にあるので、AWS VPC を用いていると VPC 内のプ
新しいリリースプロセスをデプロイした - fujimuradaisuke's blog
今やっているサービス、ちょっと障害が増えてきたので、リリースプロセスを変えました。 ざっくり言うと、今までmasterを全部デプロイしていたのを、金曜日以外の毎日一回、手動の確認をしてリリースするようにした。実際のドキュメント(Wikiです)を日本語にしてダイジェストで紹介してみようと思います。 ちなみにこのサービスは複数のアプリケーションがあって、今回対象にしたのはそのうちの主要な3つのみです。 ブランチ戦略 developを本流として、そこにトピックブランチからプルリクエストを出す。masterは常に本番環境に自動的にリリースされる*1 急ぐときはHotfixとしてmasterに直接プルリクエストを出してもOK*2。 リリース手順 HipChatで「リリースするよ」ってアナウンスする developからmasterにプルリクエストを出す HipChatでHubotに頼むと、Jenkin
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Capistrano 3系でRails 5.1のデプロイ[rbenv][ruby2.4]![Capistrano 3系でRails 5.1のデプロイ[rbenv][ruby2.4]](https://cdn-ak-scissors.b.st-hatena.com/image/square/c2ea7e72d0d7f3ba6c237909f321e67ffbdaa24e/height=288;version=1;width=512/https%3A%2F%2Fmorizyun.github.io%2Fimg%2Fog_image.png)
