入門 継続的デリバリー
継続的デリバリーとは、コード変更を必要に応じて迅速かつ安全に、継続的にリリースできるようにするための開発手法です。本書は、初めて継続的デリバリーに取り組む読者向けに、必要な知識とベストプラクティスをていねいに紹介する入門書です。基本的な概念や技術、アプローチの解説はもとより、章ごとに事例を使用しながら、継続的デリバリーを実践する際に直面するさまざまなシナリオを取り上げ、その全体像・世界観を包括的に理解することができます。 序文 はじめに 第1部 継続的デリバリーとは 1章 『入門 継続的デリバリー』へようこそ 1.1 継続的デリバリーは必要？ 1.2 なぜ継続的デリバリー？ 1.3 継続的デリバリーとは 1.4 インテグレーション 1.5 継続的インテグレーション 1.6 何をデリバリーするのか？ 1.7 デリバリー 1.8 継続的デリバリーと継続的デプロイメント 1.9 継続的デリバリー
Tilt
A toolkit for fixing the pains of microservice development. Are your servers running locally? In Kubernetes? Both? Tilt gives you smart rebuilds and live updates everywhere so that you can make progress. Tiltfile # Deploy: tell Tilt what YAML to deploy k8s_yaml('app.yaml') # Build: tell Tilt what images to build from which directories docker_build('companyname/api', 'api') docker_build('companynam
リリース頻度を毎週から毎日にしてみた - NTT Communications Engineers' Blog
目次 目次 はじめに NeWork とは リリース頻度変更の背景 それまでの運用 課題 実現方法 解説 日次でワークフローが起動するようにする main ブランチの HEAD にタグが付与されていなければ付与する develop に差分があれば main へのマージを自動で行う 細かな工夫点 main の内容を develop に自動で取り込む 祝日はリリースしないようにする 自動リリース・自動 develop → main マージの制御 Slack にリリース結果を通知する stg 環境に変更内容を通知する その他の考慮 上司への事前説明の省略 スプリントレビュー前のリリース リリースノート 品質面 リリース頻度を変えてみて おわりに はじめに こんにちは、NeWork 開発チームの藤野です。普段はオンラインワークスペースサービス NeWork のエンジニアリングマネジメントをしています
ニーリーのSREによるリリースサイクルの改善〜「隔週深夜1回→1日2回」にリリース頻度を向上させた道のり〜｜株式会社ニーリー公式note
プロダクト開発グループSREチームの大木（おおぎ）と菊地です。 突然ですが、皆さんのプロダクトではリリースはどのように行われていますか？ 実は、ニーリーのメインプロダクトであるPark Direct（パークダイレクト）はわずか1年前まで隔週に一度、深夜0時からしかリリースを行うことができていませんでした。開発組織の健全性の指標として使われる d/d/d (deploys / a day / a developer) という指標で、1年前の我々は d/d/d=0.015ぐらいのスコアでした。この指標は d/d/d >= 0.1 が健全な組織としての目安となるそうです（※1）。かなりの開きがありますね・・・。 この記事では、SREチームのリリースエンジニアリングと開発チームのプロセス改善により、リリースの頻度が大幅に向上したというお話をしたいと思います。 ※1 『エンジニアリング組織論への招待
DHH氏によるコンテナデプロイ自動化ツール「Kamal 1.0」正式リリース。ベアメタルや仮想マシンに自動デプロイ、ゼロダウンタイムのアプリ更新も可能
DHH氏によるコンテナデプロイ自動化ツール「Kamal 1.0」正式リリース。ベアメタルや仮想マシンに自動デプロイ、ゼロダウンタイムのアプリ更新も可能 Ruby on Railsの作者として知られるDavid Heinemeier Hasson（DHH）氏は、Dockerコンテナに対応したアプリケーションのデプロイ自動化ツール「Kamal 1.0」をリリースしました。 Kamalはアプリケーション（群）の構成とデプロイ先のサーバ（群）のIPアドレスなどの基本的な情報を設定すると、あとは仮想マシンやベアメタルサーバ、クラウドのサーバインスタンスなどにDocker環境の構築からアプリのデプロイ、トラフィックの切り替えまでを自動的に行ってくれる、デプロイ自動化ツールです。 Kamal 1.0 has shipped. Deploy your web apps anywhere from bare
改めてECSのデプロイ方法を整理する - NRIネットコムBlog
こんにちは。梅原です。 今日はECSのデプロイタイプについて改めて整理します。 ECSのデプロイ方法は3つあります。 ローリングアップデート Blue/Greenデプロイ 外部デプロイ の3つです。 この記事ではローリングアップデートとB/Gデプロイについて流れをおさらいします。 ECSの前段にALBを置いた構成を例にします。 ローリングアップデート ローリングアップデートの流れを見る B/Gデプロイ B/Gデプロイの流れを見る ローリングアップデートとB/Gデプロイの比較 最後に ローリングアップデート ローリングアップデートとは、稼働中のECSタスクをそのまま新しいタスクに置き換える方法です。一番オーソドックスなデプロイ方法なのではないでしょうか。 ECSのみでデプロイすることができ、設定箇所も主に後述する2つだけなので手軽にできます。ですがデプロイ中は新旧のタスクが混ざる状態となるた
Branch Deploy Action: GitHub Actions でブランチデプロイと IssueOps を試す - kakakakakku blog
The GitHub Blog の記事 Enabling branch deployments through IssueOps with GitHub Actions を読んで「branch deployments（ブランチデプロイ）」というデプロイ戦略を知った💡 プルリクエストを main ブランチにマージしてから本番環境にデプロイするのではなく，プルリクエストを直接本番環境にデプロイして，動作確認の結果問題なしと判断できてからプルリクエストを main ブランチにマージするという流れが特徴的❗️そして，デプロイに異常があってロールバックする場合は main ブランチをデプロイして復旧する💡 記事に載ってるブランチ画像（Merge Deploy Model と Branch Deploy Model）は非常にわかりやすく見てみてもらえればと〜 github.blog IssueOp
ecspressoを活用したECSデプロイの改善 - LayerX エンジニアブログ
2月にバクラク事業部Platform Engineering部DevOpsチームに入社したid:itkqです。7月はLayerXエンジニアブログを活発にしよう月間 ということで、この記事では、私が入社してから中心となって進めた、ECSサービスのデプロイの改善について書いています。 バクラクのインフラ 私が所属するバクラク事業部では、バクラク請求書をはじめとする、BtoB向けのSaaSを提供しています。SaaSは主にAWS上でホストしており、サービスの大半がECS Fargateにデプロイされています。昨年、プロダクト開発をイネーブルメントするEnablingチームが発足し*1 、今後の事業成長を支えられるようなソフトウェアアーキテクチャと周辺の仕組みが発達してきています。以下の記事で述べられているように、モノレポかつサービスが多数存在します。 tech.layerx.co.jp DevOp
「GitHub Actions extension for VS Code」パブリックベータ公開。VSCodeからワークフローの実行と監視、管理が可能に
「GitHub Actions extension for VS Code」パブリックベータ公開。VSCodeからワークフローの実行と監視、管理が可能に GitHubは、Visual Studio Codeの拡張機能としてGitHub Actionsによるワークフローの実行や監視、管理を可能にする「GitHub Actions extension for VS Code」のパブリックベータ公開を発表しました。 GitHub Actions extension for VS Codeを使うことで、VSCodeの画面上からGitHubのActionを実行し、ビルドやデプロイなどの状態を監視できるようになります。 問題が発生した場合にはログの参照も可能。
ヤフーでは開発迅速性と品質のバランスをどう取ってるか（2022年）
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog 皆さんは「No Measurement, No Improvement」という言葉をご存じでしょうか。これは「測れないものは改善できない」という意味で、熱力学者であるウィリアム・トムソン博士の言葉とされています。 下図はGoogle社のDORA（DevOps Research and Assessment）を参考にして作成しました。開発スピードとサービスの品質を改善するためには計測が必要です。計測のための4つの指標を紹介します。 四つの指標で計測し、開発スピードとサービスの品質を改善 開発スピードの分析に利用する指標は、1つ目が「Change Lead Time（開発が始まってから本番にデプロイされるまでの時間）」、2つ目が「De
Bottlerocket ECS Updater に Deep Diveする | Amazon Web Services
Amazon Web Services ブログ Bottlerocket ECS Updater に Deep Diveする この記事は A deep dive into Bottlerocket ECS Updater を翻訳したものです。 先月 (2021 年7 月)、Amazon Elastic Container Service (Amazon ECS) に最適化された Bottlerocket AMI の一般提供を発表しました。この記事では、Bottlerocket ECS Updater に焦点を当ててみたいと思います。Bottlerocket ECS Updater は ECS クラスターにインストールできるサービスで、Bottlerocket のコンテナインスタンスを最新の状態に保つことができます。 サービスの仕組みを詳しく説明する前に、Bottlerocket でアップデ
Serverless Framework から lambroll + Terraform に移行しているお話
はじめまして、wind-up-bird です。スタディストの SRE Unit に入ってから約半年が経ちました。今回は社内で利用している Serverless Framework を lambroll に移行しているのでその話を少し書いてみようと思います。 これまでの開発の流れスタディストでは AWS Lambda および周辺リソース（AWS IAM や Amazon API Gateway など）の管理はこれまで Serverless Framework を利用していました。開発からリリースの流れは以下の通りです。 Lambda の開発serverless.yml を作成開発者がデプロイ担当者に連絡する担当者がローカルの環境から serverless deploy を手動実行Serverless Framework 導入当初は管理しているリソースが少なくこの運用でもあまり問題になりません
AWSにおけるALB&NLBのBlue/Greenデプロイメント設計 - How elegant the tech world is...!
はじめに どうも、iselegant です。 前回、執筆した商業誌について本ブログで紹介させていただいたところ、大変多くの反響がありました。 コメントをくれた方、書籍に関心を持っていただいた方、本当にありがとうございます🙇 AWSコンテナ設計・構築[本格]入門 | 株式会社野村総合研究所, 新井雅也, 馬勝淳史, NRIネットコム株式会社, 佐々木拓郎 |本 | 通販 | Amazon 本日から少しの間、分量調整と締め切りの都合上、商業誌では執筆しきれなかった AWS 設計に関するサイドトピックについて、本ブログ上でご紹介したいと思います。 今日はALB (Application Load Balancer) と NLB (Network Load Balancer) の Blue/Green デプロイメントに関する設計がテーマです。 AWS で Web アプリケーションの可用性とパフォ
数時間かかる週一リリースを毎日何度も爆速でできるようにするまで / CI/CD Conference 2021
CI/CD Conference 2021
Denoの分散ホスティング「Deno Deploy」ベータ2公開。FiIe System API追加、クラッシュレポートなど
Denoの分散ホスティング「Deno Deploy」ベータ2公開。FiIe System API追加、クラッシュレポートなど Node.jsの作者であるライアン・ダール（Ryan Dahl）氏が新たに立ち上げた企業「Deno Company」は、サーバサイドでJavaScript/TypeScriptを実行するためのオープンソースのフレームワーク「Deno」と、その分散ホスティングである「Deno Deploy」を提供しています。 Denoは、ライアン・ダール氏がNode.jsを開発した経験を活かし、より優れたサーバサイドのJavaScriptランタイムとして新たに開発しているものです。V8 JavaScriptエンジンをベースにしており、JavaScriptだけでなく、TypeScriptとWebAssembly（WASM）にも対応します。 Deno Deployは、その名前の通りDen
永続複数ブランチ運用は『単一のコードベース』と言えるのか / What are your justifications for the multi-branches?
Talked at "CI/CD Conference 2021 by CloudNative Days" #CICD2021. https://event.cloudnativedays.jp/cicd2021/talks/1129
AWS App Mesh を使用した Amazon ECS でのカナリアデプロイパイプラインの作成 | Amazon Web Services
Amazon Web Services ブログ AWS App Mesh を使用した Amazon ECS でのカナリアデプロイパイプラインの作成 この記事は Create a pipeline with canary deployments for Amazon ECS using AWS App Mesh を翻訳したものです。 この記事では Amazon Elastic Container Service (Amazon ECS) で実行されるアプリケーションのカナリアデプロイ戦略を、AWS App Meshと組み合わせて実装する方法を説明します。ALB の加重ターゲットグループを使用した AWS CodeDeploy でのカナリアデプロイを行う場合はこちらの記事を参照してください。 Amazon ECS や Amazon EKS などのコンテナオーケストレータを利用することで、世界中
もうリリースは怖くない ― 大きな変更を安全に本番適用するTips - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、AWS版kintoneのDevOpsエンジニアをしている@ueokandeです。 AWS版kintoneは2019年9月のローンチから現在まで、幾度となく機能改善をしてきました。 ローンチ当時よりも利用者が増え、スケーラビリティのために内部設計を大きく変更することもあります。 先日公開したメール送信の設計変更もその1つです。 blog.cybozu.io 安定運用のために必要なリリースではありますが、実装を大きく変えることで不具合混入のリスクもあります。 それだけではなく、パフォーマンス改善のつもりが、本番環境に投入して逆にパフォーマンス低下が発覚するというケースもあります。 この記事では、大きな変更を安全にリリースするためのTipsを紹介します。 記事の最後ではSpring Bootの実装例と、Kubernetesでの実現方法も紹介します。 切り戻し戦略 大きな変更を安全にリ
ECSを運用で使っていて難しいと思った点 - アジャイルSEの憂鬱
ECSを触っていて今まで難しいと思ったことを雑にまとめておく。 ECSを仕事で運用するときに必要な知識が多すぎる。こんなの社内に1人AWSマスターいないと無理だ...— 神速 (@sinsoku_listy) 2021年8月10日 タスクロールとタスク実行ロールの違い ECSを長く触っているのに、いつも混乱する。 タスクロール コンテナ内の権限 S3やSESなどの権限をつける タスク実行ロール コンテナ外の権限 ECRやParameter Storeの権限をつける ECSのデプロイ時に静的ファイルが404になる ECSを触った初期に遭遇した。 詳細は以下のQiitaの記事が分かりやすい。 参照: ECSのデプロイ時に一定確率で静的ファイルが404になる問題を回避する 回避する方法はいくつかある。 静的ファイルをS3に置く CodeDeployの OneAtATime を使う CodeDep
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon ECS デプロイツール ecspresso 開発5年の歩み
