GitHubでプルリクエストを一発で作るURL
CI/CD と プルリクエスト こちらの記事のようにブランチとリリースが紐付いていることがあります。 その際、自動でPRを作る対応をしても良いんですが、デプロイフロー上難しかったりサクッと対応したい場合などはREADMEにPR作成リンクなど貼っておくだけで簡易的なリリース運用は出来そうです。 それを実現するためにどのような方法があるかを調べてみました。 普通にPRを作るURL 最初にブランチを push するときにプルリクエストを作るリンクが画面に表示されていると思います。 確認すると以下のようなフォーマットになっていますね。 もちろんこのフォーマットでも良いんですが、実はカスタマイズしにくいエンドポイントなので他の方法を探します。 ブランチをカスタマイズしてPRを作るURL 実は公式ドキュメントに クエリパラメータを利用したプルリクエストの作成 についての記述があります。 ここを見ると、
Cloud RunがGitと連携して勝手にデプロイできるようになったのでやってみた - inductor's blog
はじめに こんにちは。inductorです。 GCPのCloud Runはご存知でしょうか。世界一簡単に単一のコンテナをデプロイできるサービスだと私は考えています。 さて、以下のようなリリースノートの通知があって、Cloud RunがGitと連携して更新まで自動でできるようになったみたいです。 Continuous deployment from Git using Cloud Build まとめるとこんな感じのことが書いてあります Cloud Buildのトリガーを使用して新しいコミットがGitリポジトリの特定のブランチにプッシュされるたびにコードを自動的にビルドしてデプロイすることで、ビルドとCloud Runへのデプロイを自動化できます。 Cloud Buildトリガーを使用してコンテナをビルドすると、Cloud Runにデプロイした後、ソースリポジトリ情報がサービスのCloud C
EC2 Container ServiceのBlue/Greenデプロイメント | Amazon Web Services
Amazon Web Services ブログ EC2 Container ServiceのBlue/Greenデプロイメント この投稿と付随するコードの作成には、下記3名による多大な貢献がありました。 コンテナ化されていないトラディショナルな環境にソフトウェアアップデートを展開するのは難しく、リスクを伴います。デプロイパッケージまたはスクリプトを記述するときは、ターゲットマシンが特定の状態にあると仮定する必要があります。ステージング環境が本番環境の正確なミラーイメージでない場合、デプロイは失敗する可能性があります。デプロイが失敗すると、アプリケーションの最後の正常なバージョンを再デプロイするまでサービス停止が起きることがあります。あなたが運用管理者だとしたら、サービス停止があると夜間に起きていなければいけないでしょう。 リリース内容の審査が終わるまでユーザーに新しいバージョンをさらすこと
AWS Application Load Balancer + Amazon ECS でDockerのホットデプロイ環境を構築した - Glide Note
TL;DR AWS Application Load Balancer(以下ALB) + Amazon ECS でDockerのホットデプロイ環境を構築した ALBのTarget GroupとECSのServiceを紐付けることで、ALB配下のコンテナの入れ替えが自動で行われるようになる ALBは先日リリースされたばかりで、私もまだ色々と検証している段階なので、内容や認識等に誤りがあるかもしれないのでご容赦下さい。(詳しい人教えてください!!) その他弊社の前提情報 GitHub + CircleCIが連携済み Docker RepoにはAmazon EC2 Container Registry(以下ECR)を利用 DeployはGitHubのデプロイブランチへのマージを契機にCircleCI経由で、Docker Pushとecs-deployでDockerデプロイを実施 準備 ALBとE
Itamae、Auto Scaling、CodeDeployを用いてdeployフローを刷新した話。そして板前をprovisioningした話。 - SmartNews Engineering Blog
その上で、新しく作り上げた deploy フローについて、雑な絵になりますが概略図を以下に示します。 主要な登場人物は Itamae Auto Scaling CodeDeploy GitHub / Circle CI となります。それぞれ追って説明をしていきます。 https://github.com/itamae-kitchen/itamae Itamae は @ryot_a_rai さんが作られた LightWeight な Chef like な OSS です。Chef で実現できた事のうち、 recipes の部分のみを切り出したようなシンプルなツールになっています。 (こちらの発表資料より引用) 弊社内で蓄積された Chef 関連のリソースを再利用・再整理するために粒度がちょうど良かったこともあり、Itamae を用いて provisioning の定義を書き直すことにしました
世界展開する大規模ウェブサービスのデプロイを支える技術 / YAPC::Asia Tokyo 2015
Miiverse とは任天堂株式会社が運営しているウェブサービスであり、世界中の Wii U やニンテンドー3DS、そして PC やスマートデバイスから利用することができます。 AWS 上でマルチリージョン構成をとり大量のサーバを抱える Miiverse のデプロイを支える技術と運用上の工夫、そして株式会社はてなと任天堂株式会社が共同で開発する Git リポジトリの同期システムの構築を通して得られた経験をもとに、大規模なウェブサービスを素早くかつ安全に改善する方法を紹介します。 ※本資料は YAPC::Asia Tokyo 2015 での発表資料となります。 http://yapcasia.org/2015/talk/show/9ec2791c-05e5-11e5-81fa-79c97d574c3a
pixivの開発フロー - pixiv_dev_flow_sezemi.md
pixiv_dev_flow_sezemi.md pixivの開発フロー 社内用のリポジトリ管理のためにGitLabを使用 pixivはPC・Touch版などがありそれぞれソースコードを一部共有しているためpixiv.gitという1つの大きなリポジトリで管理している 社内で一番大きく関わっている人も多いリポジトリ pixiv.gitは1.4GBくらい（昔は2GB超だったが工夫して減らした）なので外部サービスのGitHubに置くと遅すぎて開発ができない GitHubの障害によりデプロイができなくなるのも困る GitHubにはファイルの容量制限など様々な制限もあるのでそういったことで悩みたくない 社内のデータセンター内で管理する必要がある GitHub Enterpriseを使えば社内のサーバー上にGitHubを立てることができる ピクシブではデータセンターの拠点が複数あるなどちょっと特殊な事
Auto Scaling環境でのBlue-Green Deploymentの切替がAWS ELBでできるようになりました。 | DevelopersIO
Auto Scaling環境でのBlue-Green Deploymentの切替がAWS ELBでできるようになりました。 超おはようございます。最近パンケーキを昼食にできるようになった城内です。 今回は、Auto Scalingのアップデートにより、AWSでのBlue-Green Deploymentの方式に新たな選択肢が増えたことを喜びたいと思います。 Auto Scalingのアップデート 先日のAuto Scalingのアップデートにより、Auto Scalingグループに対するELBの付け外しができるようになりました。 Attach or Detach Load Balancers in Your Auto Scaling Group (What's New) Attach and Detach Elastic Load Balancers from Auto Scaling G
「開発生産性を上げるためのデプロイ戦略」講演メモ (AWS Summit Tokyo 2015) #AWSSummit - 元RX-7乗りの適当な日々
メモった。間違い等あるかもしれませんが、その場合はごめんなさい。 デプロイとは あらゆるコードやバイナリ、アセットなどの配布をデプロイと定義 インフラストラクチャーの構築はプロビジョニングとする なぜデプロイに注目する必要があるのか AWSのイノベーションのペース 合計1000以上の新サービス、新機能をリリース フィードバックループを回し続け、顧客の期待に応え続ける Amazon.comのデプロイ 平日のデプロイ間隔 11.6秒 1時間あたりの最高デプロイ回数 1079回 1回のデプロイで平均10000台のホストに変更を加える 1回のデプロイで最大30000台のホストへの変更 Two pizzaルール 1チームの大きさは、2枚のピザで全員お腹いっぱいになれる規模 それを保って頻繁にデプロイできるレベルに 作った人が運用をやるポリシー クロスファンクショナルチーム 各チームメンバーが何ができ
[レポート]AWS Elastic Beanstalk, AWS OpsWorks, AWS CodeDeploy, AWS CloudFormation を使った自動デプロイ #AWSSummit | DevelopersIO
AWS Summit Tokyo 2015のTA-05: Tech Deep Dive by Amazon:「AWS Elastic Beanstalk, AWS OpsWorks, AWS CodeDeploy, AWS CloudFormation を使った自動デプロイ」のレポートです。 スピーカーはAmazon Data Services Japanの舟崎健治氏です。 レポート Introduction 多くのシステムの場合、EC2/ELB/RDS/S3の4つを組み合わせて構築する Webアーキテクチャ 一方で、デプロイの自動化まで考えられているシステムはまだ多くない デプロイの自動化がなぜ必要なのか？はこのセッションの対象としない 本セッションでは、どうやってデプロイを自動化するか？を紹介する Elastic Beanstalk、OpsWorks、CodeDeploy、CluodF
![[レポート]AWS Elastic Beanstalk, AWS OpsWorks, AWS CodeDeploy, AWS CloudFormation を使った自動デプロイ #AWSSummit | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/823f7aca4a5fc29780be05be8d6f7645655fcd6c/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2015%2F05%2Faws_summit_tokyo_2015.png)
デプロイ自動化を進めるためのチェックリスト | Ryuzee.com
いままで色々なところで言ってきたことをだらだらとまとめてみました。 計画および準備段階要求される品質の定義をおこなうDevとOpsの双方で情報が共有されるようにするいつデプロイを開始するのかを明らかにするデプロイの際にインフラを変更する必要はあるのかを明らかにするデプロイを行う時間帯、行わない時間をあらかじめ決めておく(休み前を避ける)ブランチ戦略、マージ戦略を決める継続的インテグレーションの戦略を決めるログの出力戦略を決めるビルドとリリースの自動化人的要素を減らす繰り返し可能にする自動作業と手作業を混ぜないビルドを自動化する誰のマシンでもビルドできるようにするユニットテスト、結合テスト、UIテストなどテストを自動化する本番にデプロイする際にコードを書換えなければならないといった実装を避ける毎回デプロイプロセスを設計するのではなく、毎回同じ方法でデプロイする毎回同じ方法が難しければ2パター
クックパッドにおけるScalable Deploymentsのスライドが興味深い - GeekFactory
クックパッドにおけるアプリのデプロイの資料が非常に興味深いので紹介します．これは @sora_hさんがRubyKaigi 2014で発表 された資料で，100台以上のサーバに短時間でアプリをデプロイする仕組みをどうやって作り上げたのかが説明されています． 以前，スライドの内容を箇条書きにまとめていたのでシェアします．最近では，Jenkins User Coferenceの発表（How We Use Jenkins? // Speaker Deck）でほんの少し引用されていたりします． 内容のまとめ スライドは90枚あります．ざっくりまとめた内容を以下に示します． 概況 140サーバに1日10回のデプロイを実施している（ピーク時） コードベースが大きい モデルだけで約 69K LOC プロダクトコードとテストコードを合わせると約 319K LOC デプロイのルール CIのビルドが成功したリビ
デプロイ考，あるいは仕組み化考 - その手の平は尻もつかめるさ
良い感じに酔っ払っているのでここ最近デプロイについて考えていることについて記す． デプロイの仕組みが単純であれば単純であるほど良い，というのは総意だと思っている． 単純な仕組みによってデプロイされるのと，複雑な仕組みによってデプロイされるのとで比較した時， 互いの結果 (つまりユーザに提供できる機能) の差が有意でなければ， 単純な仕組みの方が総コストが低くて良い． で，ここで出てくるのが「仕組み化」ってやつで， 仕組み化はそうした総コストを下げる為にやる， つまり作業を楽ちんにするためにやると思うんだけど本当に楽ちんなのかどうかは 冷静に考える必要があると思っている． (あるいは例えば，それオーバーエンジニアリングやん，とか) 最初のうちは仕組み化できて嬉しい，最高，これで平和が訪れた！ みたいな感じになると思うんだけど， ゆくゆくは色々な事情から変更変更そして怒涛の変更が訪れて，仕組み
#10 Consulと連携するpull型デプロイツール stretcher - KAYAC engineers' blog
tech.kayac.com Advent Calendar 2014 10日目担当の @fujiwara です。 最近書いている stretcher というデプロイツールの紹介をしたいと思います。 長いので3行で push型デプロイはホスト台数が増減しやすい環境に適さない 各種問題を解決するpull型デプロイツールを書いた Consul と連携するよ 中央ホスト配布(push)型デプロイの問題点 カヤックの自社サービスでは久しく Archer というツールを利用し、中央ホストから各デプロイ対象ホストに rsync でファイルを配布する形のデプロイを行っていました。ここではこれを push 型と呼びます。 push型のデプロイは、ホスト台数が頻繁に増減する環境で以下のような問題があります。 新しくホストが起動してきた場合に、中央ホストからデプロイを行ったあとでないと (古い状態で起動してい
AWS News Blog
Top Announcements of the AWS Summit in New York, 2023 It’s probably no surprise that generative artificial intelligence and machine learning were the stars of the show, but there were several other bright lights from the day-long cloud conference. New Seventh-Generation General Purpose Amazon EC2 Instances (M7i-Flex and M7i) Today we are launching Amazon Elastic Compute Cloud (Amazon EC2) M7i-Flex
GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー
少し前までアプリケーションのデプロイと言えば capistrano などをコマンドラインから叩いてデプロイ、みたいなことをやっていたが、最近は少し様子が違うのでそのやり方、KAIZEN platform Inc. での事例を紹介する。 GitHub のイベントを契機に CI as a Service にデプロイを担当させる GitHub で Pull Request を送って開発するのが前提になっているのは以前にも紹介した。 最近は Travis CI や CircleCI などに代表される CI (Continuous Integration) as a Service があって、CI も自分たちで環境を構築しなくてもクラウドに任せることができる。KAIZEN では CircleCI を積極的に使っている。 これらの CI as a Service は基本的に GitHub と連携するこ
私家版のgoでホットデプロイの仕組み、もしくは椅子もマサカリも投げられたくないときの気遣い : D-7 <altijd in beweging>
なんかごく一部に補足されているので、念のため軽く説明しておきます。 masahiro nagano@kazeburo某所のlestrratさんのgolangなアプリはhot-deployが可能になってる。サーバはserver_starter経由で起動されていて、バイナリ消してHUPを送ると自動でビルドしなおしてプロセスを入れ替えてくれる。便利 2014/04/30 12:18:31 これ、ベストな方法だとは思っていないんだけど、最初にこれを書いた当時の考え方は以下の通り： これは自分の部署で初めて 本番に設置するgoアプリである一次対応をする人は自分とは限らない細かいコード内容の修正はともかく、明らかなバグっぽいものの修正（例：SQL文の変更）などを自分以外の人間が施した後にサーバーを簡単に再コンパイル＋再起動するする方法がないと椅子が降ってくる事が容易に予想される Apache::Log
シンプルなデプロイツールを書いているという話 - Kentaro Kuribayashi's blog
デプロイツールにcapistranoを使っているのですが、経年劣化により、何をやっているのか意味不明になり、機能追加しようにもどうにもならない感じになってきたので、もっとシンプルなものを作ってみようというわけで、ちょっとやってみています。 https://github.com/kentaro/cinnamon 設計指針は以下の通り。 role/taskという枠組みはcapistranoと同じ というか、このモジュールは、role/taskの管理 + アルファだけを提供する 設定のset/get コマンド実行(run/sudo) リモートでのコマンド実行(remote) (いまはないけどstreamみたいなのも欲しい) 普通、デプロイツールというのは、デプロイ先のディレクトリ構成をいい感じにしてくれたり、VCSとの連携を上手いことやってくれたりするわけですが、このモジュールはそういうことはし
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
クックパッドはなぜ開発しやすいのか // Speaker Deck
AWS上でのWebアプリケーションデプロイ
