内部ソースの推進について考える

フォークベースの pull request ワークフローは、これを使用すればだれでもプロジェクトに参加できるようになることから、オープンソースプロジェクトで広く使用されています。

変更を提供するには、既存の共同作成者である必要も、プロジェクトへの書き込みアクセス権を持っている必要もありません。

このワークフローは、オープンソースのためだけのものではありません。フォークは、会社内の内部ソースワークフローのサポートにも役立ちます。

フォークする前は、pull request を使用してプロジェクトに参加できます。

ワークフローを使用すると、新しいブランチをリポジトリにプッシュしたり、pull request を開いてチームからコードレビューを取得したり、Azure Repos でブランチポリシーを評価できるようにしたりすることが簡単になります。

ボタンを 1 つクリックするだけで、pull request を main にマージして、承認されたコードをデプロイすることができます。

このワークフローは、チームでの共同作業に最適です。しかし、会社内の別のプロジェクトで見つけた単純なバグを自分で修正したい場合はどうでしょうか。

使用しているのは自分であっても、開発しているのが他のチームという機能をプロジェクトに追加する場合はどうでしょうか。

ここでフォークの出番です。フォークは、内部ソースの実践で中心的な役割を果たします。

内部ソース

内部ソースは、"内部オープンソース" と呼ばれることもあり、これを使用すると、ファイアウォール内でのオープンソースソフトウェア開発のすべての利点がもたらされます。

プロジェクトでの開発者による共同作業が会社全体で促進されるよう、ソフトウェア開発プロセスが公開されます。

オープンソースソフトウェアコミュニティで広く使用されているものと同じプロセスが使用されます。

ただし、組織内では、コードが安全かつセキュリティで保護された状態に保たれます。

Microsoft では、内部ソースアプローチを多用しています。

Azure Repos によるサポートによって、会社全体で 1 つのエンジニアリングシステムを使用するよう標準化する取り組みの一環として、Microsoft は、社内全員のすべてのプロジェクトに対してソースコードを公開しました。

内部ソースに移行する前の Microsoft は、Windows で作業するエンジニアのみが Windows のソースコードを読み取ることができるという、"サイロ化" された状態でした。

Office で作業する開発者のみが、Office のソースコードを読み取ることができました。

そのため、Visual Studio で作業するエンジニアが、Windows や Office でバグを見つけたり、新しい機能を追加したいと思ったりしても、どうしようもありません。

しかし、Azure Repos を利用して会社全体に内部ソースを提供する方法へと移行すると、簡単にリポジトリをフォークして再参加できます。

変更を加える個人は、読み取りとフォークの作成を行うことができればよく、元のリポジトリへの書き込みアクセス権を持っている必要はありません。