プロダクトとしての GitLab

Principles - Processes - Categories - GitLab the Product - Being a PM - Leadership

プロダクトとしての GitLab

シングルアプリケーション

私たちは、Convention over Configuration (設定より規約) に基づく DevOps ライフサイクル向けのシングルアプリケーションが、優れたユーザー体験を提供すると信じています。その利点は、Wikipedia の Convention over Configuration ページから引用できます。 「開発者が行う必要のある意思決定の数を減らし、シンプルさを獲得しつつ、必ずしも柔軟性を失わない」。GitLab では、ワークフローの非定型的な側面のみを指定すればよいのです。ハッピーパスは 計画からモニタリングまで摩擦がありません。

私たちは、ライフサイクル全体を 1 つのアプリケーションにもたらし、全員が貢献できるようにする、同時並行 DevOps のためのプロダクトに注力しています。顧客が愛していると伝えてくれたもの、つまりシングルアプリケーション戦略、イテレーションのペース、ユーザーへの深い注力に傾倒しています。

初期のイテレーションでこのユニークな属性を活用する機会を検討してください。アプリケーションのさまざまな部分に機能を統合することで、初期のイテレーションの採用を増やすことができます。その他の利点:

• 統合された最小限の実用的な機能は、統合されていない高度な機能よりも有用である可能性があります。

すべての機能をアプリケーションの他の部分と統合する必要はありませんが、2 回目または 3 回目のイテレーションで機能をより深く統合することで独自または強力な利点があるかどうかを検討すべきです。

GitLab.com

GitLab.com は GitLab Enterprise Edition を実行しています。

コードのメンテナンスを容易に保ち、誰もがすべての取り組みの恩恵を受けられるようにするため、GitLab.com のコードベースを Enterprise Edition のコードベースから分離しません。

複雑さを避けるため、GitLab.com のティアと GitLab セルフマネージドのティアは同じ名前になっています。

GitLab.com サブスクリプションのスコープとティア

GitLab.com のサブスクリプションは、名前空間ベースで動作します。これは以下を意味します。

• 個人の名前空間 (例: JaneDoe/*)
• グループの名前空間 (例: gitlab-org/)

つまり、グループレベルの機能はグループ名前空間でのみ利用可能です。

パブリックプロジェクトは Ultimate を無料で利用できます。 パブリックグループは Ultimate を無料で利用できません 。その理由は:

• これは、機能、ライセンス、グループの構造化方法に大きな複雑さを加えます。私たちはパブリックグループを抑制したくありませんが、プライベートプロジェクトのみを持つパブリックグループが Ultimate のすべての利点を得られるのは公平ではありません。それでは GitLab.com のライセンス購入がほぼ意味をなさなくなります。
• グループレベル機能のすべての価値は、組織、つまりマネージャー以上を対象としています (スチュワードシップを参照)。すべての機能を無料で提供することの目的は、オープンソースプロジェクトを可能にし、奨励することです。したがって、オープンソースプロジェクトに対するグループレベル機能の利点は大幅に減少します。
• 代替ソリューションは理解するのが難しく、メンテナンスも困難です。

確かに、これは複雑であり、機能を実装する際にプロダクトマネージャーを混乱させる可能性があります。 これを簡素化するアイデアは歓迎します (ただし、個人名前空間をグループと同等にすることはアイデアではないことに注意してください。それは他の問題を引き起こします)。

機能のティアと価格設定に関するさらなるガイダンスについては、機能のティア付けガイダンス を参照してください。

非推奨と削除のポリシー

定義

非推奨に関する用語を参照してください。

これは破壊的変更ですか?

定義により、削除は破壊的変更です。いくつかの例外を除き、以下の質問のいずれかに「はい」と答える場合、その変更は破壊的変更とみなされ、重大なビジネスリスクがない限り回避すべきです。

• この変更は、機能の継続性を確保するために顧客からのアクションを必要としますか? (例: オブジェクトストレージのバックグラウンドアップロードを削除すると、ユーザーはオブジェクトをサポートされているオブジェクトストレージプロバイダーに移行する必要がありました)
• この変更は、顧客のワークフローやタスクを中断させますか? (例: MR で「WIP」プレフィックスのサポートを削除すると、ユーザーは代わりに「Draft:」プレフィックスを使用する必要がありました)
• この変更は、プロダクトの他の部分を機能不全にしますか? (例: 証明書ベースのクラスター統合を削除すると、ユーザーは GitLab Managed Apps 経由で追加のアプリケーションをインストールできなくなります)

API における破壊的変更の特別な定義については、以下を参照してください。

• REST API の破壊的変更
• GraphQL API の破壊的変更

Experiment または Beta 機能については、Experiment、Beta、Generally Available 機能のサポートを参照してください。

破壊的変更の例外

マイナーリリースで破壊的変更を導入することはポリシーに反します。顧客に支障をきたす可能性があるためです。ただし、いくつかのまれな例外があります。

• 破壊的変更を遅らせることが、マイナーリリースで出荷することと比較して、全体的に顧客に 著しく より否定的な影響を与えると GitLab が判断した場合。
• 統合されているサービスがシャットダウンした場合、マイナーリリース中に統合を削除できます。

すべての場合において、PM または EM は破壊的変更のリクエストプロセスに従う必要があります。

機能の非推奨化と削除

機能の非推奨化と削除は、ユーザーへの混乱を最小化することが重要であるため、特定のプロセスに従う必要があります。プロセスを進めるにあたり、削除されようとしている、または削除された機能の現在の状態を指定するために、deprecated または removed という言葉を使用してください。

機能の非推奨化と削除のプロセス

ドキュメントに概説されたプロセスに従ってください。

GitLab.com の破壊的変更ウィンドウ

私たちは 1 日に何度も GitLab.com への変更をデプロイしています。これらは継続的デリバリープロセスの一部であるため、これらの変更 (破壊的変更を含む) は顧客にとって予測しにくいものです。

GitLab 17.0 から、GitLab.com への破壊的変更がロールアウトされる固定ウィンドウを導入しました。固定ウィンドウは、メジャーリリース日に先立つ 3 週間の月曜日、火曜日、水曜日に設定され、通常 X.11 リリース日に続きます。これがどのようなものかの詳細な例は、私たちの 17.0 導入 Issue で確認できます。

破壊的変更は、破壊的変更ウィンドウ中にのみ有効化されるべきです。これは、破壊的変更が機能フラグの背後にある場合、変更 (機能フラグ) は、伝達された期間外で顧客のワークフローが影響を受けないようにするため、これらのウィンドウの 1 つの間にのみ切り替えられるべきであることを意味します。

プロダクトマネージャーは、非推奨化と削除プロセスの一環として、該当する場合に非推奨化/削除が公に伝達された破壊的変更ウィンドウに合わせられることを確認する責任があります。

2023 年 6 月、すべての非推奨化と削除が非推奨化ページに表示されるようにプロセスを変更しました。 お知らせは、削除されるマイルストーンによってグループ化されています。非推奨化のお知らせ日は各項目の下に記載されています。

構文の非推奨化プロセス

Our CI syntax keeps evolving. We cannot support all keywords indefinitely, so deprecating and removing keywords is inevitable.

GitLab does not have a versioning system for CI/CD configuration. Therefore, it is critical to over-communicate our deprecation purposes to our users and take the necessary precautions to reduce the impact on their projects. Deprecating a keyword is risky because it will break all pipelines using it, and in some cases, users are not aware of the keyword they use in their pipeline. The deprecation process described below is similar to the deprecating and removing features process, with additional steps to reduce the risks which involved with removing a CI/CD keyword.

1. Deprecation notice - Syntax removal introduces a breaking change, as outlined in our deprecation process, we must notify the community and customers, which means including a deprecation notice in the monthly release post.

2. Track keyword usage - Tracking keyword usage should begin as early as possible. It is a mandatory step that helps estimate the user impact, timing, and needed effort. The more users use the keyword, the more time it takes to remove it (It took more than four years to move from remove to deprecation for ’type’ keyword).

3. In-app warning - Provide our users with an in-app notification that we plan to remove a keyword they use in their pipeline. Our customers will get a notification in each run of the pipeline that uses the deprecated keyword. The warning will be printed:

   • At run time on the pipeline page and logs.
   • In the pipeline editor, while authoring a pipeline.

   This step is optional if the keyword usage is relatively low (Recommend minimal reach of ~5% impacted users).

4. Keyword removal - The keyword will be removed from our code and schema and should happen in a major version. Once removed, using the keyword will result in a lint error.

機能の命名

新しい機能の命名や既存機能のリネームは、悪名高いほど難しく、多くの意見に敏感です。

名前を選ぶ際の要素

• AWS の命名状況を避けるため、機能が何であるかを明確に表現する必要があります。
• 迷ったときは、ユーザビリティのヒューリスティックに従うべきです。
• 業界で一般的であるべきです。
• GitLab の他の既存概念と重複してはいけません。
• できるだけ少ない単語で構成されるべきです (人々が短縮名を使わないようにするため)。
• 名前から単語を削除しても、なお一意であるべきです (できるだけ少ない単語で命名するのに役立ちます)。
• 私たちはまた、プロダクトに識別的ではなく説明的な名前を与え、名前でサードパーティの製品やサービスを参照する際は前置詞を使用するべきです。詳細はプロダクト原則を参照してください。

プロセス

• これをできるだけ早く議論し始めることを強く推奨します。
• 幅広い意見を求め、議論を慎重に検討してください。
• 関連する領域の責任 PM が最終的な決定を行い、命名を遅らせないようにすべきです。
• 命名は、機能のリリースのブロッカーになるべきではありません。
• コンセンサスに達することは目標ではなく、名前を確立するための要件でもありません。

リネーム

既存の機能のリネームの基準は非常に高く、特に長年使用されている機能ではそうです。 有効な (ただし排他的ではない) 理由としては、以下のようなものがあります。

• 新しいブランディングの機会
• 新しい隣接機能の導入に伴う混乱の軽減
• 既存機能のリファクタリングに伴う混乱の軽減

機能をリネームする際は、data/features.yml で名前を変更する MR から始めて、カテゴリをリネームするプロセスに従います。承認のために、所属セクションのプロダクトディレクターおよびエンジニアリングディレクターのレビューを依頼します。任意で、透明性のため、テクニカルライター、エンジニアリングマネージャー、プロダクトデザインマネージャー、プロダクトデザイナーを含むコメントを追加します。

機能をリネームする際は、ドキュメント、ブログ、ディレクションページ、競合情報の更新も検討する必要があります。

What’s New を使用したユーザーへのアップデートの伝達

What’s New は、GitLab.com とセルフマネージド GitLab の機能で、各リリースのハイライトを伝達するために使用されます。各メジャーリリース後、リリースから 3〜10 個のハイライトと、それらの使用を開始するための関連ドキュメントへのリンクを含む yaml ファイルが公開されます。

「?」アイコンの上に小さな通知ドットが表示され、ユーザーがメニューの「What’s new」をクリックすると、アップデートを含むドロワーがスライドして表示されます。

What’s New の目標は、GitLab の最も重要な変更にユーザーが容易に気付けるようにすることで、私たちのすべての変更や機能アップデートに常に最新の状態を保てるよう支援することです。

GitLab における権限

このセクションを既存機能の使用と新しい機能の開発のガイダンスとして使用してください。

1. Guest はプライベートプロジェクトでアクティブな貢献者ではありません。彼らはコメントを残したり、Issue を作成したり、表示したりすることしかできません。
2. Reporter は読み取り専用の貢献者です。リポジトリには書き込めませんが、Issue には書き込めます。
3. Developer は直接の貢献者であり、明示的に制限されていない限り (例: ブランチ保護を通じて)、アイデアから本番までのすべてにアクセスできます。
4. Maintainer はスーパー Developer です。master にプッシュしたり、本番にデプロイしたりできます。 このロールは、メンテナーやエンジニアリングマネージャーが持つことが多いです。
5. Admin 専用機能は /admin でのみ見つけることができます。それ以外では、Admin は最も高い権限 (Owner) と同じです。
6. Owner は本質的にグループ管理者です。グループへのアクセス権を付与でき、破壊的な機能を持っています。
7. Auditor は /admin、グループ設定、プロジェクト設定にアクセスできません。Auditor は他のすべての領域に対する読み取り専用アクセス権を持っています。

権限システムを明確かつ一貫したものに保つために、可能な限り、各リソースで権限設定を追加し続けるのではなく、一般的なフローに合わせてロールを改善すべきです。

多くのユーザーを持つ大規模なインスタンスでは、プロジェクト作成、コードレビュー、チーム管理を 1 つのロールで持つことは不十分かもしれません。 そのため、長期的には、権限システムが次のロールを明示的にカバーするようにしたいと考えています。

1. Owner。破壊的でワークフローを強制する権限を持つロール。
2. Manager。プロジェクトを稼働させ続け、新しいチームメンバーを追加するなどのロール。
3. コードレビュー、貢献の承認、その他の開発関連タスクを行うための、より高度な開発ロール。

上記すべては、既存のロールを段階的に改善することで達成できます。

権限に関するドキュメント

セキュリティパラダイム

私たちのセキュリティパラダイムは、Secure Strategy ページで見つけることができます。

Secure Team エンジニアリングハンドブックも参照してください。

統計とパフォーマンスデータ

伝統的に、アプリケーションは使用状況とパフォーマンスに関する有用な情報を管理者にのみ表示しています。しかし、ほとんどの GitLab インスタンスには少数の管理者しかおらず、彼らは頻繁にサインインしない可能性があります。これは、興味深いデータが、他のチームから学ぶようチームを動機付けたり、Issue を特定したり、単に組織内の人々に採用状況を認識させたりするのに役立つにもかかわらず、めったに見られないことを意味します。

そのため、パフォーマンスデータと使用状況統計は、デフォルトですべてのユーザーが利用できるようにすべきです。ドイツなど一部の国の法律では管理者専用にすることが要求されるため、これを任意で管理者専用に制限できることも同様に重要です。

国際化

GitLab は英語で開発されていますが、他の言語の貢献をサポートしています。

GitLab は常に英語をデフォルトとします。私たちは、ユーザーの言語/場所/国籍を推測してそれに基づいて言語を変更することはありません。 ユーザーの好みをシステム設定から安全に推測することもできません。 技術的なユーザーはこれに慣れており、通常はオフィスでの言語が違っても、英語でソフトウェアを書きます。

パフォーマンス

高速なアプリケーションは、より優れたアプリケーションです。コアなユーザー体験から、統合の構築や API の使用まで、すべてのクエリが高速で、すべてのページが高速にロードされれば、すべてが優れたものになります。新しい機能を構築する際、パフォーマンスは最優先事項であるべきです。

私たちはすべてのページを高速にするように努力する必要があります。これは、新しいページがパフォーマンス負債に追加することは許容されないことを意味します。出荷時には、高速であるべきです。

1 つのオブジェクトを持つ人から数千のオブジェクトを持つ人まで、すべてのケースを考慮する必要があります。

GitLab.com のパフォーマンスに関するハンドブックページを読み、そこに示されている Speed Index 目標に注目してください (パフォーマンスの詳細な概要が必要な場合は徹底的に読んでください)。それから:

• 新しいページとインタラクションが Speed Index 目標を満たすことを確認してください。
• 既存のページは、新機能や変更の導入によって大幅に遅くなるべきではありません。
• 非常に遅くロードされるページ (特定の条件下のみであっても) は、それらのパフォーマンスに関する作業や、ページのロード速度の改善につながる変更 (ページネーション、表示データを減らすなど) を優先することで高速化すべきです。
• ロードに 4 秒以上かかる (Speed Index) ページは、遅すぎると考えるべきです。
• 可用性とパフォーマンスの優先度ラベルを使用して、パフォーマンスに関する Issue を伝達し優先順位を付けます。

可用性とパフォーマンスの優先度ラベルに従って、改善を影響に応じて優先順位付けする必要があります。 頻繁に訪問されるページは、訪問者がほとんどいないページよりも優先されるべきです。 しかし、ページのロード時間が 4 秒以上に近づく場合、それらはもはや使用可能ではないと見なされ、最も早い機会に修正すべきです。

クローズドソース JavaScript の制限

加えて、GNU の倫理的基準を満たすため、GitLab.com 上のすべての JavaScript コードは自由 (フリー) でなければなりません。 これについての詳細は GNU のウェブサイトで読むことができます。

サイクルタイムが重要な理由

サイクルタイム (または: 価値実現までの時間) を監視、可視化、改善する能力は、GitLab のプロダクトにとって基本的です。短いサイクルタイムにより、以下が可能になります。

• 変化するニーズへのより速い対応 (つまり、パックが向かう先にスケートする)
• より小さな変更の出荷
• リグレッション、ロールバック、バグのより良い管理 (より小さな変更を出荷しているため)
• より正確な予測の作成
• 顧客のニーズにより速く対応できるため、顧客体験の改善に集中できる

GitLab に新しい機能を追加する際、私たちは顧客のサイクルタイムを削減するものに焦点を当てる傾向があります。これが、私たちがConvention over Configurationを選択し、ソフトウェア開発ライフサイクル全体の自動化に注力する理由です。

新しいプロジェクトをセットアップし、あらゆる種類のソフトウェアを出荷するために必要なツールのパイプラインを構築する際のすべての摩擦は、GitLab を使うときに消えるはずです。

他と上手く連携する

私たちは、誰もが常にすべてに GitLab を使うわけではないことを理解しています。特に最初に GitLab を採用するときはそうです。私たちはあなたが GitLab のその部分を愛しているから、GitLab の使用を増やしてほしいと考えています。GitLab は他と上手く連携するため、GitLab の 1 つの部分のみを使用していても、素晴らしい体験になるはずです。

GitLab は、多くの一般的なアプリケーションへの組み込みインテグレーションが同梱されています。私たちは、Slack、JIRA、Jenkins 向けに世界最高のインテグレーションを持つことを目指しています。

他の多くのアプリケーションが GitLab と統合しており、私たちは新しいインテグレーションをテクノロジーパートナーページに追加することにオープンです。GitLab との新しいインテグレーションは、シンプルな webhook から Project Service まで、豊かさと複雑さがさまざまです。

GitLab は、他のプロダクトとのコラボレーションを拡張する新しいインテグレーションが作成されることを歓迎・サポートしています。 GitLab は、GitLab 内で行えるほぼすべてのことに対する API を提供することで、他と上手く連携します。 GitLab は、外部アプリケーションの認証プロバイダーになることもできます。

GitLab が DevOps ライフサイクル全体のシングルアプリケーションであることと、既存の DevOps ツールとの統合によるより良いユーザー体験のサポートとの間には、いくらかの自然な緊張があります。私たちはまず、シングルアプリケーション体験の改善への取り組みを優先し、次にパートナーの豊かなエコシステムを可能にすること、そして 3 番目に他のツールとのより広範なエコシステムとの統合の改善を優先します。GitLab はオープンソースであるため、これによって貢献者が不足しているもののインテグレーションを追加することが妨げられるべきではありません — それが GitLab プロダクトビジョンに合っている限り。

貢献する時間がなく、顧客である場合、私たちはあなたが必要とする API の追加やインテグレーションを設計するために喜んで協力します。

ページのソースコードを見る - ページの編集 - please contribute.