いう題で、現在自分のチームが行っている取り組みについて書きます。利用している技術の話というより、課題に対して何を考えて取り組んでいるかといった類の話になるためご留意下さい。いうパブリッククラウドサービスを提供しています。本サービスを提供するために様々なアプリケーションが開発・運用されており、2016年にリリースされてから今でも機能の改善や拡張が行われています。メニューとして新しくリリースされました。アプリケーションのリリースについて、弊部署では以下の図のようなプロセスを必要としています。(各会議名は仮称です)これらの会議はそれぞれ異なる観点でリリース対象のアプリケーションを見ることで、事前に大規模な障害を防ぐことを目的としています。実際に弊社で大規模障害と定めている障害はここ二年程ありません。当リリースプロセスには明らかに欠点があるということが皆さんも分かると思います。現状、リリース対象のアプリケーションがどんな規模であれ原則これらの会議を通すことになっています。これによりアプリケーションの開発者はアプリケーションの開発以外に注力せざるを得なくなり、結果としてリリースサイクルが遅くなってしまっています。チームを結成しました。一般的に、エラーバジェットに収まる程度の品質を維持しつつ高速なリリースサイクルを実現する手法を指すと自分は理解しています。ことを最初の目的として定めました。チームにて運用しています。動作することを想定しています。特徴として以下があります。チームの用意したデプロイフローを利用することで、開発チームがリリース工程の責務を負わない形にするこの取り組みにより、以下の会議をシステムに置き換えることが可能であると考えています。チームが用意し、統一されたリリースプロセスでリリースを行う。いうイベントでも紹介しました。アプリケーションのリリースを自動で実施しています。Deployment中にある正常性確認のステージにて開発者の用意したシナリオテストを新バージョンのアプリケーションに対して実行します。話題に上がりますが、私たちはこれを採用しませんでした。ユーザトラフィックを徐々に新バージョンのPodに振り分けるデプロイ戦略です。これにより、バージョンアップ起因の障害発生時においても影響を最小限にすることが可能です。発生時において少なからずユーザ影響が出てしまいます。アプリケーションのことを熟知しないと策定出来ないものです。いった作業は今の段階では手がつけられないと判断しました。採用し、ユーザトラフィックではなくテスト用トラフィックを用いた環境固有バグの確認を行っています。グループ内で定期的に行われている勉強会にて自分が発表しました。登壇資料は以下になります。より、リリース時にシナリオテストが実行されることでアプリケーションが本番環境で動作することが担保されます。シナリオテストが失敗した際においても本番環境に影響なく切り戻る仕組みとなっています。見立て、「絶対に決壊しない川作り」と呼んでいます。見立てたイメージ図です。システムに置き換えるための必須要件となります。決壊なく川の下流のどちらかに必ず流れ着きます。決壊する恐れがあります。値が書き換わってしまった場合が挙げられます。適用した時点で外部からアプリケーションへの疎通性がなくなりサービス断が発生してしまいます。この問題は実際にステージング環境にて発生した事象です。適用してしまいサービス断が発生しました。いう選択肢もなくはないと思います。ことであるため、「やっぱり川が決壊しうるんだったら会議をやらなきゃダメじゃん」となってしまわないためには当問題をシステム的に発生させないようにする必要があると考えました。利用できると考えています。いったポリシを定義することができます。いうソフトウェアがあります。完成すると考えています。いいつつ物事に絶対は無く、現状決壊しうるケースとしてユーザ定義された変更不可なフィールドに漏れがあった場合が挙げられます。廃止を推し進めています)これからの取り組み上記の取り組みによりリリースに必要な会議の数が減り、リリースの際に開発チームにかかる負担が軽くなると考えています。して以下の会議が必要となっていることが課題であると認識しています。完了していないため、その先の話である上記の課題の解決法はまだチームの共通認識として定まっていません。そのため、これらの問題をどのように解くかについて、現状の私見として以下にまとめます。リリースしたい新規機能の説明や当機能の実装及びテスト項目を開発部署の責任者に共有するための会議です。当会議にて新規機能のリリース要求の承認を行うことで、当リリース起因の障害が発生した場合の責任を部署の責任者に委譲するといった目的もあります。自分はこの会議を完全に無くすことは出来ないと考えています。リリース内容がバグフィックス程度のものであってもメジャーバージョンアップ等の大きなものであっても同じ人に対して同じ手順でこの会議をしている現状を見ると、工夫のしようはあると感じます。1つは、リリース内容のレベルに応じて誰に対して会議を実施するかを分けることです。することが可能なのかなと思います。適切に行うことで、エラーバジェットの範囲内であれば承認を得ることすらせずにリリースすることが可能ではないかと考えています。いった意識付けを行うことが必ず必要になります。取り組みに関する啓蒙活動を継続的に行おうと思っています。人が該当アプリケーションを深く理解しないと決められないものです。チームメンバを割り当てて開発チームと密接に関わることが必要なのかなと考えています。再策定を行うことも必要です。用いてシステム化するという以下の事例はとても参考になりました。開発チームと別部門にある運用・サポートチームに対しリリース対象のアプリケーションの機能についての情報共有を行います。チームが運用するため当会議は必要なさそうに思えますが、そうはいかなそうだということが見えています。運用・サポートチームはお客様の問い合わせに対する回答を行うことが業務の一つとなるため、新規機能が実装された際はそれを認知する必要があります。共有を両チーム間で行うことが必要になります。必要だろうと予想しています。それを実現するために自分は以下の2通りの方法を思いつきました。1つは、運用・サポートチームが該当アプリケーションのドキュメントを熟知していれば良いという考えです。この方法は、運用・サポートチームが自分が実装したわけでは無いアプリケーションを詳細に知る必要があるという障壁だけでなく、開発者がアプリケーションに関するドキュメントを事細かに記述し随時整備しなければならないといった障壁も存在します。いう場を設けた」というストーリーも考えられるほどですし、現実的な解では無いと自分は思っています。チームを同じにしてしまうという方法です。「基盤運用とお客様のサポートを行う」のに適しているように思えます。営みに注力できるのかといった点に怪しさを感じています。この課題に対して自分はこれだという解決策を持てていないです。どのように皆さんはこの課題を解決しているのか、ぜひ教えていただきたいです。ために取り組んでいることや考え方について述べました。現状自分が考えうる理想かつ実現可能そうなリリースプロセスについてを述べました。は荒削りな箇所があると思います。当記事を読んでくださった方に「こうやったほうがいいんじゃない?」であったり「似たような問題をこうやって解いたぜ!」といった意見や疑問点等があれば、ぜひ当記事のコメントに書いていただけると嬉しいです。upLoginユーザーは見つかりませんでした。