CodeBuild,CodeDeploy,CodePipeline３つ使ってCI/CDの環境構築してみた | フクロウラボテックブログ | Fukurou-labo Tech Blog
CodeBuild,CodeDeploy,CodePipeline３つ使ってCI/CDの環境構築してみた 先日、Developers Summit 2019 に初めて参加してきました。 広いジャンルのセッションがあって大変勉強になったんですが、 その中でも一際興味を惹かれたのが、このセッションでした。 CI/CDを使い倒して数段上のソフトウェア開発をしよう！ フクロウラボではCircleCIを使っているのですが、「なぜCIを使うのか？」という質問にちゃんと説明ができないなと思っていたのと what’s CD????聞いたことすらない・・・状態だったので聞いてきました。結果よかった。 簡単にセッション内容をまとめてみました。 CIとは？ 継続的インテグレーションのこと（Continuous Integration） 主にプログラマーのアプリケーション作成時の品質改善や納期の短縮のための習慣の
AWSのCodeDeployでエラーになったらAgentを試そう！ - Qiita
AWSのCodeDeploy使っている人ってどのくらいいるんでしょう？ 先日こんなのも書きましたが http://qiita.com/hardreggaecafe/items/7ff3ada575a1100fa4a2 あまりドキュメントがなくて正直苦労しております。 ここに書いたこともAmazonのサポートに聞いたことも一部書いてます。 自分の場合はCircleCIからS3まではコンテンツ持ってこれて、その後CodeDeployが EC2にデプロイしようとしてエラーになるというのを何回か経験しています。 その時のエラーはこちら。 "The overall deployment failed because too many individual instances failed deployment, too few healthy instances are available for
Code4兄弟の連携デプロイを東京リージョンで試す - サーバーワークスエンジニアブログ
こんにちは、技術４課の多田です。 2016年も終わりますが、皆さんにとってどんな一年だったでしょうか？ 私は、サーバーワークスに入っていろいろと変化があった１年だったなぁと思います。 来年も引き続き頑張っていきたいと思います。 さて、今回は、CodePipelineが東京リージョンの他以下のリージョンに展開されたので、Code４兄弟の連携による東京リージョンのEC2へのデプロイを試したいと思います。 オハイオフランクフルトシンガポールシドニーサンパウロ AWSの発表記事は、以下になります。 AWS CodePipeline Available in Asia Pacific (Tokyo) Region 今回の構成イメージ 今回は、バージニアに配置したCodeCommit/CodeBuildの連携をCodePipelineのワークフローで作り、ビルド/テストしたビルド済みのデプロイモジュー
AWS CodeDeployを使ってPHPアプリケーションをデプロイしてみた - Qiita
AWS CodeDeployを使って、お手製デプロイシェルやJenkinsおじさんから卒業しよう！というお話です。 今回はPHPアプリケーションをS3経由でデプロイしてみようと思います。 AWS CodeDeploy is 何 Q: AWS CodeDeploy とは何ですか? AWS CodeDeploy は、Amazon EC2 インスタンス、およびオンプレミスで稼働するインスタンスを含む、さまざまなインスタンスへのコードのデプロイを自動化するサービスです。AWS CodeDeploy を使用すると、お客様はアプリケーションの複雑なアップデート処理、デプロイ中のダウンタイムの回避、新規機能の迅速なリリースが容易になります。AWS CodeDeploy を使用すると、エラーを起こしやすい手動操作やインフラストラクチャのサービススケールの必要性を排除しながら、デプロイの自動化を行うことが可
CodePipeline で CodeCommit/CodeBuild/CodeDeploy を繋げてデリバリプロセスを自動化してみた #reinvent | DevelopersIO
こんにちは、藤本です。 AWS re:Invent 2016 で CodeBuild がリリースされました。CodePipeline のビルドプロセスに CodeBuild を置くことができるようになりました。 CodeBuild に関しては以下の記事をご参照ください。 【速報】フルマネージドのビルドサービスCodeBuild爆誕 #reinvent 今回は CodeCommit、CodeBuild、CodeDeploy を CodePipeline で繋げて、デリバリプロセスの自動化を試してみました。 概要 昨今のシステム開発はユーザーの要望をより早く、より多く取り入れることを要求され、リリース頻度が増えてきたことに伴い、デリバリプロセスの自動化がデファクトスタンダードとなってきました。デリバリプロセスにはソースコード管理、ビルド、テスト、デプロイという 4つ主なフェーズがあります。下記
Travis CI + AWS CodeDeploy + Slack - Qiita
この記事は mediba Advent Calendar 2017 の10日目です。 @mediba-moritake です。au WebポータルやUQライフのサーバーサイド開発をしています。 今回はUQライフの一部で使用しているTravis CI、 AWS CodeDeploy、 Slack を使用した、PHP アプリケーション(Amazon Linux, Nginx, PHP-FPM, PHP5.6)のデプロイを紹介したいと思います。 AWS CodeDeploy とは EC2 インスタンスに対するアプリケーションのデプロイを自動化するデプロイサービスです。 概要 今回は下記 GitHub ブランチへのマージで、各環境へのデプロイを行います。 deployment/production deployment/staging deployment/develop { "Version":
GitHubへのpush時に自動デプロイする方法まとめ - Qiita
はじめに 「GitHubへのpush時に自動デプロイする方法」を調べる機会がありましたので備忘録としてまとめます。 Webhookのみを使った単純なものからJenkinsやAWSとの高度な連携を行うものまで様々な形態がありますが、ここでは連携形態と使用シーンの代表的と思われる例をいくつかピックアップして下記します。 目次 GitHubのWebhookによる連携 Jenkinsとの連携 AWS CodeDeployとの連携 AWS CodeDeploy + 外部クラウドCIでの連携 おわりに 1. GitHubのWebhookによる連携 GitHubのレポジトリ設定にある「Webhook」機能を設定することで、通知先URL（サーバ）側でトリガーとなるプログラムを動かします。 連携手順は、 pushを通知したいレポジトリの設定からWebhookを登録 Webhookで指定したURLにトリガー用
[新機能] CodeDeployのELB対応によるダウンタイムなしのリリース | DevelopersIO
渡辺です。 待望のアップデートがきました！ AWS CodeDeployのELB対応です。 AWS CodeDeployは、ターゲットEC2インスタンスにエージェントを常駐させ、アプリケーションをデプロイするサービスです。 例えば、EC2インスタンスにJavaのSpringアプリケーションの実行環境を用意し、CodeDeployを利用してJAR（WAR）ファイルをデプロイすることができます。 しかし、システムがELB配下にある場合、ELBからのヘルスチェックを考慮する必要がありました。 デプロイが行われると、そのEC2インスタンスは一時的にヘルスチェックに失敗します。 したがって、ELBからのヘルスチェックに成功するまで待たなければ、一時的なサービス断が発生するのです。 これまでは、フックスクリプトでELBのヘルスチェックが成功するまでデプロイを完了させない方法で回避していました（Code
![[新機能] CodeDeployのELB対応によるダウンタイムなしのリリース | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/a13e8a84f51eb581d192f74e16514fade527aa28/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2014%2F11%2FAWSCodeDeploy.png)
CircleCIとCodeDeployの連携による開発自動化の実践（続） - Qiita
こちらの記事ではCircleCIとCodeDeployの、基本的な連携しかたを紹介しました。この記事では、ステージング環境と本番環境のデプロイを分離する手順を紹介したいと思います。 考え方 作成しやすさとセキュリティのバランスを配慮した結果、最初の記事で作成した以下を使いまわします。 IAMロール CodeDeployのアプリケーション CircleCIがデプロイを行うためのIAMユーザ 一方、以下は新しく作成します。 リビジョン保存用のS3バケット CodeDeployのアプリケーション内のデプロイグループ（deploy_group） また、インスタンスとブランチの関係は以下。 本番環境 → 今まで使用したインスタンスを使いまわす ステージング用の環境 → 新しく作成 GitHubのproductionブランチ → 本番環境用ブランチ GitHubのmasterブランチ → ステージング
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
