2023年1月から2024年5月までの AWS Infrastructure as Code 関連のアップデートを解説しています。JAWS-UG CDK支部 #14 でお話させていただきました。 https://jawsug-cdk.connpass.com/event/317935/
継続的デリバリーとは、コード変更を必要に応じて迅速かつ安全に、継続的にリリースできるようにするための開発手法です。本書は、初めて継続的デリバリーに取り組む読者向けに、必要な知識とベストプラクティスをていねいに紹介する入門書です。基本的な概念や技術、アプローチの解説はもとより、章ごとに事例を使用しながら、継続的デリバリーを実践する際に直面するさまざまなシナリオを取り上げ、その全体像・世界観を包括的に理解することができます。 序文 はじめに 第1部 継続的デリバリーとは 1章 『入門 継続的デリバリー』へようこそ 1.1 継続的デリバリーは必要？ 1.2 なぜ継続的デリバリー？ 1.3 継続的デリバリーとは 1.4 インテグレーション 1.5 継続的インテグレーション 1.6 何をデリバリーするのか？ 1.7 デリバリー 1.8 継続的デリバリーと継続的デプロイメント 1.9 継続的デリバリー
※本記事は2022年1月22日に公開された記事の翻訳版です。 この記事は、Developer Productivity Engineering Campブログシリーズの一環として、Platform Infraチームの Daisuke Fujita (@dtan4)がお届けします。 メルカリでは、すべてのクラウドインフラを宣言的構成で管理することがプラットフォームの中核となる考え方の一つです。メインのクラウドプロバイダーはGoogle Cloud Platform（GCP）であり、HashiCorp Terraformを使用してインフラをコードとして管理しています。Platform Infraチームは、すべてのTerraformワークフローを安全に管理するための社内CIサービスを提供しています。 Terraformはリソースプロビジョニングのためにクラウドプロバイダーのクレデンシャルを必要と
多数のヘルステックサービスを企画・開発しているメドピアが、リモートワーク継続中でも事業成長を加速させたプロダクト開発の事例や技術的な知見を紹介する「事業成長を加速させたエンジニアリングのウラ側」。ここで「Deploy Rails apps in 2021」テーマに正徳氏が登壇。まずは過去のレポートをもとにした目指すべきデプロイの頻度と、デプロイ改善のために取り組んだことについて紹介します。 自己紹介 正徳巧氏（以下、正徳）：「Deploy Rails apps in 2021」というタイトルで発表します。ちょっと私も緊張しているので、ビールを飲みながら発表させてください。 自己紹介です。正徳と言います。会社に入社して1年半ぐらいで、CTO室のSREという部署に所属しています。SNSなどは@shinsokuというハンドルネームで活動しています。よろしくお願いします。 SREでなにをやっている
本連載は、最新のソフトウェア開発の課題点を解決する手段であるフィーチャーフラグ（Feature Flag）について、概要や導入方法、ベストプラクティスを紹介します。第1回は、フィーチャーフラグとはなにか、どのようにしてプロダクト開発を変えていくのか、そのメリットと導入の際の懸念点を説明します。 はじめに 本連載はフィーチャーフラグについての連載です。最新のソフトウェア開発の課題点を解決する手段であるフィーチャーフラグに焦点をあて、フィーチャーフラグとは何なのか、どういった機能を提供するのか。フィーチャーフラグのメリット・デメリットを、具体例を使って詳細に説明します。また、導入前に考慮すべきことや、フィーチャーフラグの実装、サービスの選定の際の注意点、効率よく、かつ継続的に使用していくためのベストプラクティスも併せて解説します。さらにはサードパーティー製のフィーチャーフラグサービスの比較を行
DevOpsDays Tokyo 2021 で使用したスライドです。 Infrastructure as Code を導入してみたはいいけれど、デプロイしてみたらなぜか上手く動かない。そんな経験はありませんか？ 本セッションでは、実際の環境を構築する「前」に、IaC のコード自体に対してテストを行…
こんにちは！ 先日最終話が放映された Dr.STONE 2 期が始まった頃、先が気になりすぎて漫画版を大人買いした CTO室 鹿児島オフィスチームのよしこ @yoshikouki です。これぞ社会人の嗜みだなと感慨深くなった30歳の春。 今回は私が運用・開発に携わっているホスティング事業部で Slack ワークフローと GitHub Actions を組み合わせて業務を改善しましたので紹介したいと思います。本改善は、サービスの本番環境に近いステージング環境へのデプロイ作業を Slack 上で行えるようにして、デプロイのための環境構築を不要にしたことに加えて必要なステップを 1 つだけにすることができました。 これまでステージングデプロイの問題点 環境構築についての比較 改善前 改善後 デプロイフローについての比較 改善前 改善後 どのようにして改善したのか 実際の操作画面と流れ 実装方法
米Amazon Web Servicesは、AWS上での開発においてDevOpsメトリクスダッシュボードのセットアップを自動化するリファレンス実装である、「AWS DevOps Monitoring Dashboard」の一般提供を3月26日（現地時間）に開始した。 AWS DevOps Monitoring Dashboardを使用することで、AWSが提供している開発者ツール全体の顧客ごとのアクティビティと使用状況のメトリクスをキャプチャ・分析して、単一のダッシュボードで表示できるようになる。AWSパイプライン環境における、DevOpsダッシュボードのセットアップを自動化するため、平均修復時間の測定、変更の失敗率、デプロイ頻度、デプロイステータス、コード変更量の測定を、迅速に始められる。 CI/CDパイプラインが実行されているプライマリAWSアカウントにテンプレートをインストールすること
Amazon Web Services（AWS）は、オンラインで開催中の年次イベント「AWS re:Invent 2020」で、DevOpsの実現を支援するマネージドサービス「Amazon DevOps Guru」を発表しました。 一般に、DevOpsの実現には、分散環境を活用しつつコードの編集、ビルド、テスト、デプロイなどの一連のツールを連係させ、本番環境でのログを収集し分析するなど、手間のかかる運用が求められます。 Amazon DevOps Guruは、AWSにおけるDevOpsの経験を元に行った機械学習により、DevOpsのサイクルの中で発生する構成ミスやリソース不足が予想される際の警告、問題が発生しそうなコードや構成に対する変更の発見、データベースのI/O性能不足に対する警告などを行ってくれるサービス。 これにより複雑で手間のかかるDevOpsの実現と運用を支援してくれるというも
データセンター構成ツールあるいはDevOpsツールなどとして知られる「Chef」を提供するChef社が、開発ツールベンダのProgress社によって買収されることが発表されました（Chefの発表、Progressの発表）。 Big News Today! We’ve entered into an agreement to acquire @Chef. Read the official announcement for all the details: https://t.co/uNF7PgFiqC pic.twitter.com/qkCCsivhnp — Progress (@ProgressSW) September 8, 2020 Chef社はもともとOpscodeという社名でしたが、データセンター構成ツールの「Chef」が成功したことで2013年に社名を製品名と同じ「Chef」に
こんにちは、GMOアドマーケティングのmizkichです。 アドテクなマイクロサービスをGCPのKubernetesで運用しています。 GMOではグループ全社の新卒エンジニアに向けて、技術力向上・適性判断を目的とした研修プログラム「GMOテクノロジーブートキャンプ」を毎年実施しています。 今年度は非常勤講師として「DevOpsで必要とされるエンジニアスキルの変化」というタイトルで登壇させて頂きました。 「DevOpsと継続的デリバリーの関係性」や「技術の進化によりエンジニアの担当領域の変化」などを踏まえ、DevOps時代のエンジニアの技術スタックの広さを解説しています。 この記事では、この講義を作る事になった顛末や発表資料の共有などをしたいと思います。 ・GMOテクノロジーブートキャンプとは 社内では略してGTBと呼んでいます。 GTBの内容を端的に言うと、一ヶ月の集中講義で新卒に成果物を
コンテナと Kubernetes の到来によりソフトウェアをデプロイおよび運用する方法は大きく変わりました。ソフトウェアはコンテナ化された分散システムとなり、Kubernetes（または類似の基盤）の上で自動化を通じて動的に管理されるものになっています。そうしたアプリケーションを開発し、本番（プロダクシ…
この記事は2017/11の以下のブログ記事の翻訳です。 blog.itaysk.com まずはじめに、翻訳を快く許可していただいた@itayskさんに感謝いたします。 3年前の記事ですが、デプロイ戦略についてここまで網羅的にまとめられた記事が日本語で見つけられなかったので翻訳してみようと思いました。 初めての翻訳記事であり、かつ翻訳時に多少の意訳を含んでいます。私の翻訳ミスがある可能性も十分にご了承ください。 何か間違いやわかりにくいところがあれば、コメントいただけますと幸いです。 無謀なデプロイ (Reckless Deployment) ローリングアップグレード (Rolling Upgrade) ヘルスチェックと監視 ロールバック 後方互換性 ちなみに ブルーグリーンデプロイ (Blue/Green Deployment) ドレイン スイッチバック ステージ ちなみに カナリアデプロ
CEL(Common Expression Language)で書いた条件にマッチしたIAM Policyを見つける / iam-policy-finder
追記（2019-02-27） : 一部表現等見直しました。論旨は変わっていないです。 Infrastructure-as-Code-is-very-tired - Speaker Deck こちらの記事を読みました。スライド内で触れられている Terraform Best Practices in 2017 - Qiita については私も読んだことがあり、以下の記事で言及させてもらっていたり。悩みますよね、 Terraform 運用。 Terraform moduleは何が嬉しいのか · the world as code 私もある程度ポリシーめいたものをもって、これはコード化するべき、これは手で作ってもいい、みたいな線を引いてはいるものの、あまりそれを言語化してみたことがなかったので、いい機会だしまとめてみます。疲れないようにするべき、コード化がすべてではない、という視点は先のスライドと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く