内部ソースの推進について考える
フォークベースのプル要求ワークフローは、誰でもプロジェクトに貢献できるため、オープンソース プロジェクトで人気があります。 変更を提供するために、既存の共同作成者である必要や、プロジェクトへの書き込みアクセス権を持っている必要はありません。
このワークフローは、オープン ソースのためだけのものではありません。フォークは、会社内の内部ソース ワークフローのサポートにも役立ちます。
従来のチーム ワークフロー
フォークする前に、Pull Requests を使用してプロジェクトに投稿できます。 ワークフローは単純です。
- リポジトリに新しいブランチをプッシュします。
- pull request を開いて、チームからコード レビューを取得します。
- Azure Repos にブランチ ポリシーを確認させます。
- 1 つのボタンをクリックして pull request をメインにマージし、コードが承認されたらデプロイします。
このワークフローは、チームでの共同作業に最適です。 しかし、会社内の別のプロジェクトで見つけた単純なバグを自分で修正したい場合はどうでしょうか。 使用するプロジェクトに機能を追加するが、別のチームが開発する場合はどうなりますか?
ここでフォークの出番です。フォークは、内部ソースを実践する際に中心的な役割を果たします。
内部ソースとは
内部ソース ("内部オープン ソース" とも呼ばれます) は、会社のファイアウォール内でオープンソース ソフトウェア開発のすべての利点をもたらします。
内部ソースは、開発者が会社全体のプロジェクトで簡単に共同作業できるように、ソフトウェア開発プロセスを開きます。 オープンソース ソフトウェア コミュニティ全体で一般的なプロセスと同じプロセスを使用しますが、組織内でコードを安全かつ安全に保ちます。
内部ソースの利点
- チーム間コラボレーション: Teams は、通常は共同作業を行わない場合でも、プロジェクトで共同作業を行うことができます。
- 知識共有: 開発者は、他のチームによって記述されたコードから学習し、それらのレッスンを自分の作業に適用できます。
- コードの再利用: 同じ機能を複数回構築する代わりに、チームは既存の作業に基づいて構築できます。
- 品質の向上: コードをレビューして貢献する人が増えるのは、通常、ソフトウェアの品質向上につながります。
- イノベーションの高速化: Teams は、ゼロから始めるのではなく、既存のソリューションを構築することで、より迅速に移行できます。
Microsoft の内部ソースの旅
Microsoft では、内部ソース アプローチを多用しています。 Microsoft は、Azure Repos に基づく会社全体で 1 つのエンジニアリング システムを作成する取り組みの一環として、すべてのプロジェクトのソース コードを社内のすべてのユーザーに公開しました。
内部ソースの前
内部ソースに移行する前に、Microsoft は "サイロ化" されていました。
- Windows で作業しているエンジニアのみが Windows ソース コードを読み取ることができました。
- Office で作業する開発者のみが、Office のソース コードを読み取ることができました。
- Visual Studio で作業しているエンジニアで、Windows または Office でバグが見つかった場合、または新機能を追加したい場合は、運が悪かったです。
内部ソースの後に次の処理を行う
Azure Repos を利用して会社全体の内部ソースに移行することで、リポジトリをフォークして貢献するのは簡単です。 変更を行う個人は、元のリポジトリへの書き込みアクセス権を必要とせず、それを読んでフォークを作成するだけです。
このアプローチでは、次の機能が有効になっています。
- チーム間のコラボレーションの向上。
- バグ修正と機能開発の高速化。
- より広範なレビューによってコードの品質が向上しました。
- プロジェクト間での作業の重複を減らしました。