DockerのPeter McKeeは、 Uffizzi の共同創設者であるGrayson Adkins(製品責任者)とJosh Thurman(開発者関係責任者)とCPメソッドに関するQ&Aを行います。
8月26日からのライブストリームをチェックしてください
Docker ビルド: Uffizziによるフルスタックの連続プレビューの有効化
(以下のトランスクリプトは、明確さと形式のために編集されています)
ピーター・マッキー: 皆さんがライブショーに戻ってくるのは素晴らしいことです。 私は継続的なプレビューのアイデアが大好きですが、何があなたたちをコンセプトに導いたのか教えてください。
グレイソンアドキンス: アイデアの核心は、しゃれを意図したものではなく、製品をより迅速に開発しようとする私たち自身の課題から生まれました。 私たちは、前進を妨げていた2つの問題を観察し続けました。
開発側では、壊れた機能をマージすることが多すぎました–そして、このすべての混合されたコードがあり、バグが導入された場所を見つけて修正することは、進歩を本当に妨げていました。 返されたチケットは常に私たちを妨げていました–古典的な2歩前進、1歩後退。
製品側では、私はすべての設計作業を行っており、製品に命を吹き込むのを見て、設計/要件を変更する必要があることに気づき続けました。 そして、私が「まだそれを見ることができますか?」と尋ねるとき。 それに対する簡単な解決策はありませんでした。 したがって、新機能を確認してフィードバックを提供するには、ブランチがマージされてQA環境にデプロイされるまで待つ必要があります。 その後、フィードバックプロセスが開始され、チケットが返されると、この「開発中」の大きなループに戻り、マージしてデプロイし、もう一度確認できます。 開発と製品の間にはあまりにも大きなギャップがありました。
当時、ウフィッツィの製品の方向性は、開発者がアプリをクラウドに簡単にデプロイできるようにする方向に進んでいましたが、同じプロセスで「メインのダーティコード」と「まだ見ることができますか」の問題を修正できることに気付いたとき、フルスタックおよびマイクロサービスアプリケーション用のプレビューエンジンとして構築したものを再利用できることに気づきました。
ジョシュ・サーマン: これに焦点を当てた他の2つの全体像の要素があります。 誰もがNetlifyやVercelのような静的なサイトプラットフォームによるフロントエンドプレビューツールの成功を見てきました。 彼らの成功は、プレビューを簡単にすることはチームにとって非常に価値があることを教えてくれましたが、より複雑なアプリケーションの概念とサポートテクノロジーを実際に形式化した人は誰もいませんでした。 そのため、プレビューの概念はフロントエンドだけでなく、構築するすべてのものに適用する必要があることに気付きました。
もう1つの主な要因は、マイクロサービスアーキテクチャとリモートワークの複雑さが、特にチームとアプリエコシステムの規模と複雑さが増すにつれて、コラボレーションをどのように困難にしているかを観察したことです。 したがって、継続的プレビューのコンセプトは、早期かつ頻繁にコラボレーションする際の障壁を取り除くことであり、機能をコーディングする開発者とそれをレビューまたは承認するチームメンバーとの間のすべての障壁を取り除くことです。
大まかに言うと、継続的プレビューは継続的なコラボレーションに匹敵するため、コラボレーション文化を促進するプロセスとテクノロジーがあり、チームの速度、サイクルタイム、リードタイム、コードの安定性が大幅に向上し始めます。
ピーター・マッキー: CP宣言を読みました( www.cpmanifesto.org / https://github.com/UffizziCloud/Continuous_Previews_Manifesto )CPの原則を概説していますが、それを書いて公開するきっかけは何ですか?
ジョシュ・サーマン: CPがどのツールやサービスよりもはるかに大きいことは明らかであり、ツールや製品と概念を混同しやすいことも認識しています。 そこで、アジャイルマニフェストからヒントを得て、CPの概念とその根底にある原則は、誰もが「なぜ?」から利益を得て理解するためにそこにある必要があると判断しました。
グレイソンアドキンス: アジャイル マニフェスト は、チームとしてソフトウェアを構築する方法の管理ドキュメントであり、CPはアジャイルの傘下にネストされたベストプラクティスであると考えています。
ピーター・マッキー: CPマニフェストを読み、それについて皆さんと数回話して、CPが戦略レベルで何であるかをよく理解していますが、戦術レベルについて教えてください、それは日常的にチームにどのように影響しますか?
グレイソンアドキンス: ほとんどのチームは、設計、開発、統合、テスト、および配信のアジャイルループに沿った同様の開発ワークフローに従います。 このプロセスに従うと、開発者はチケットを受け取り、ブランチをチェックアウトして開発を開始します。 要件を満たしていると思ったら、PRを開いてチケットをマージする準備ができていることを示します。
このプロセスに、さまざまな機能に取り組んでいる開発者の数を掛けると、マージする準備ができている機能がX個になります。 ある間隔でCI(継続的インテグレーション)を実行すると、QA環境に新機能のバッチが作成され、このプロセスで初めて、機能をコーディングした開発者以外の誰かがレビューする準備が整います。
このプロセスの問題は、ゲームのQAが遅すぎることです。 機能がマージされてデプロイされると、問題を早期に発見して機能ブランチレベルで対処するのではなく、バグを見つけて修正するのが10倍難しくなります。
開発者がCPメソッドを使用して新しいコードをプッシュすると、マージすることなくQA化でき、開発者がGitワークフローからコンテキストを切り替える必要もありません。 プレビューによってコラボレーションの障壁が取り除かれ、開発 - プレビュー、開発 - プレビューの反復プロセスがより速く行われ、開発プロセスの早い段階でも行われるようになりました。
より文字通りの意味では、従来はアドオン機能として機能していた開発プロセスにQAを導入しています。
ジョシュ・サーマン: 開発チームや製品チームではなく、一般的にチームと言っていただけてうれしいです。 ほとんどの組織が開発チームと製品チームにタスク編成されているのを目にしますが、その構造はコラボレーションの妨げになる可能性があると思います。 CPは、製品の成功に貢献するすべての人を意味する「チーム」のプロセスです。
ピーター・マッキー: 皆さんはコラボレーションの障壁について言及しましたが、チームが現在直面している障壁は正確には何ですか?
ジョシュ・サーマン: いい質問。 テストのためにチームの全員がアプリケーションに簡単にアクセスできるようにする最もクリーンな方法は、アプリケーションをクラウドにデプロイし、安全な URL エンドポイントを介して到達できるようにすることです。 ここで強調しておきたいのは、エンドポイントは、例として、フルスタックアプリケーションや、APIやフロントエンド要素などの個々のコンポーネントをテストすることです。
アプリケーションのバージョンをデプロイするには、ホスティング環境が必要であり、特に複雑なアプリケーションやマイクロサービスベースのアプリケーションの場合、その設定を行うのは簡単な作業ではありません。 ほとんどのチームには、テスト、QA、ステージング、運用などの永続的な環境があり、DevOps チームと運用チーム メンバーによって維持されます。 1 つの機能ブランチをテストするためだけに新しい環境をセットアップすることは、大きな障壁です。
CP メソッドは、目的主導のライフサイクルを持つオンデマンドホスティング環境を呼び出します。 それらは機能ブランチをプレビューしてテストするために立ち上がっており、その機能がマージされた後に削除されます。 これがテクノロジーの出番であり、これがウフィッツィの得意なことです。 Uffizziは、プレビューを容易にするポリシーベースのトリガーを使用してオンデマンドホスティング環境を完全に自動化する既製のソリューションをチームに提供します。 テスト環境は、必要なときに必要な時間だけ用意できます。
また、この方法では、永続的なQAまたはテスト環境がダウンし、ほとんどの日をその修正に費やさなければならない場合に、単一障害点も削除できることを付け加えます。
グレイソンアドキンス: もう一つの障壁は、DevOpsの専門知識です。 一例として、20 +行のDocker Composeファイルから1000 +行のYAMLファイルに移行すると、複雑さが大幅に向上します。 DevOpsの専門知識は、多くの場合、組織内のボトルネックであり、自動化されたソリューションでそれらに対する要求を減らすことができれば、それは大きなメリットです。
DevOpsのベストプラクティスに従うために、構文的にはdocker-compose.yml(バージョン3.9に基づく)と同じですが、いくつかの追加の入力があるuffizzi-compose.ymlを介して、コードとしてのインフラストラクチャを中心に製品を集中させました。
しかし、アクセシビリティを向上させることを目的としたGUIとテンプレートの概念もあります-CPの概念は、あらゆる規模とスキルレベルのチームに利益をもたらすものであり、そのような場合にDevOpsの力の乗数として機能したいと考えています。
ピーター・マッキー: 障壁といえば、チームがCP手法を採用する際の最大のハードルは何だと思いますか?
ジョシュ・サーマン: 離陸する方法は、実際に増殖し始めるほど使いやすいテクノロジーと組み合わせる必要があります。 NetlifyとVercelが行ったことを再び参照するために、フロントエンドプレビューがここ数年で実際に普及するほどシンプルにしました。
もちろん、これはフルスタックおよびマイクロサービスアプリケーションのコンテキストでUffizziでやろうとしていることです。 ホスティング環境と展開の管理の複雑さを抽象化することで、CPの実装を容易にする非常に特殊なツールを提供しています。
グレイソンアドキンス: もう一つの問題は、「十分に良い」という慣性を克服することだと思います—誰もが今仕事を成し遂げているのに、なぜ彼らはビジネスの新しい方法を必要とするのですか?
これは、すべての新しいプロセスとテクノロジーで同じハードルです。 アジャイルの前は、ウォーターフォールで十分でした。 コンテナオーケストレーションの前は、VM(仮想マシン)で十分でした。 ですから、アーリーアダプター期間を経て、最終的には競争上の優位性が、組織がCPを実装する必要があるほど、または取り残されるリスクがあるようになると思います。
ペテロ： ウフィッツィ から期待できることを締めくくるとき、ロードマップには何がありますか?
グレイソンアドキンス: いくつかのエキサイティングな新機能が展開されています。 短期的には、画像レジストリとコラボレーションソフトウェアの両方との統合を拡大しています。 現在、すべての主要なクラウドプロバイダー(AWS、Azure、GCP)でイメージレジストリとの統合を展開しています。 その後、今後数か月の間に、リポジトリに Gitlab と Bitbucket を追加し、コラボレーション側に Slack、Jira、Microsoft Teams、Asana を追加する予定です。
ピーター・マッキー: さて、これは素晴らしかったです、私はあなたの時間とあなたのソートリーダーシップに本当に感謝しています。 これが組織の構築とテストの方法にどのようにゲームチェンジャーであるかがわかります。 CPとUffizziが開発コミュニティにどのように利益をもたらし続けるかを楽しみにしています。
Dockerに関するご質問がございましたら、Twitterでお気軽に連絡し、 コミュニティスラック に @pmckee してご参加ください。
ウフィッツィに関するご質問は、Twitterでお気軽にご連絡 @uffizzi_ いただき、 ウフィッツィのユーザー コミュニティのスラックであるジョシュ・サーマン(@JoshThurman19)またはグレイソン・アドキンス(@GraysonAdkins)にご参加ください。
CPマニフェストはこちらからご覧いただけます www.cpmanifesto.org
そして、ここのオープンソースリポジトリ- UffizziCloud / Continuous_Previews_Manifesto:ソース: https://cpmanifesto.org
フィードバック
「連続プレビュー(CP):プレビューするまでマージしない」に関する0の考え