Cloud Foundry （CF）開発プロセス、オープンソースモデルの機能、および個人的な経験について簡単に説明します。
2013年、IBMがBluemixの内部ベータを開始したときにプラットフォームのアクティブユーザーになり、今年初めにCloud FoundryをPOWER8アーキテクチャに移植することに参加し、10月中旬からCFコアチームのメンバーになり、CF Dojoを渡しました。 しかし、まず最初に。
Cloud Foundryについて詳しく説明したり、Cloud Foundryについて説明したりすることはしませんが、最低限必要な事実を以下に示します。 CFは、VMWareが開発し、後にPivotal Softwareに移行したサービスとしてのプラットフォーム（PaaS）です。 ソースコードが開かれましたが 、現在は CFプロジェクトのインキュベーターがまだ残っています。 少し後に、Pivotal、IBM、VMWare、EMC、GE、Intel、SAPを含むCloud Foundry Foundationが作成され、現在50以上の組織が含まれています。 当初、プラットフォームはRubyで記述されていましたが、その後コンポーネントの一部はGoで書き直されました。
これから話を続けます。 春には、POWER8でCFのわずかに動作するバージョンが既にあり、コミュニティとコードを共有することにしました。 コンポーネントの1つ（ BOSH ）に対してプルリクエストを行い、待機を開始しました。 しかし、何も起こりませんでした。 OpenStackの開発経験があり、すべてが活気に満ちていました。遅かれ早かれ誰かがGerritのパッチにアクセスし、コメントし、評価し、パッチを更新し、数か月-上流の2行を作成しました。 運が良ければ、数週間の時間があるかもしれません。 一般的に、次のことを理解し、理解し始めました。
CFは異なるオープンソースモデルを使用します。 OpenStackで、初心者からPTLまでのすべてがレビューのためにコードをGerritに送信し、コアチームメンバーから2つの+2を収集し、残りから-1を取得しないことに苦しむ場合、CFには2つのアクセスレベルがあります。 BOSHチームのトラッカーなど、特定のタスクにフルタイムで取り組んでいるコアチームがあります。 これらはCloud Foundry Foundation内の企業の従業員で、その一部はgitリポジトリに直接アクセスできます。 残りはプルリクエストを介して機能します。プルリクエストの一部は通常のリクエストよりも高速に処理されます。その理由を以下で説明します。 同じ理由で、正式なコードレビューシステムはありません。
実際には、CFはアジャイルプロセスを使用します。その主な要素はTDDとペアプログラミングです。 はい、ペアプログラミング、XPを覚えていますか？ Windows XPではなく、eXtremeプログラミング。 これがコアチームの仕組みであり、このモデルはコミュニティ全体に推奨されます。 明らかに、これは個々の貢献者に特定の要求を課すため、CFチームはコードレビューによるフィルタリングではなく、トレーニングと信頼を重視しています。 このために、Cloud Foundry Dojoプログラムが作成されました。
道場は日本の武道を練習する場所ですが、CF道場で戦う必要はありません。 このプログラムはコミュニティメンバーに公開されており、参加は無料です。 プログラム自体は非常にシンプルです-新しい開発者（できればカップル）は、CFチームメンバーと少なくとも6週間働きます。 3週間後、新しい同僚から何が改善できるかについてのフィードバックを受け取り、6週間後、チームに進捗が見られる場合、黒帯を受け取ります。 本当に得られない。 信頼の信用を獲得し、この開発者からの変更はチームによってはるかに早く受け入れられ、さらに彼または彼女はチームの一員となり、一般的なタスクに取り組むことができます。
サンフランシスコのPivotalオフィスでCF Dojoを体験しました。 別のホールは最近、マサチューセッツ州ケンブリッジにEMCを開設しました。 IBMはまもなくResearch Triangle Parkにオープンします。 通常、1つのチームで作業します。私の場合は、クラスターを管理するコンポーネントであるBOSHでした。 標準サイズのチーム、6〜12人の開発者、1人のプロダクトマネージャー。 チーム間にはローテーションがあります。そのため、年長者、つまりアンカー、チームをめったに（または決して）離れない開発者がいます。 週は反復計画会議（IPM）で始まり、回顧会議で終わります。 最初に、プロダクトマネージャーは何をする必要があるかを伝え、2番目に、チームは何がうまくいかなかったかを言います。 毎日はスタンドアップミーティングから始まり、昨日何が行われたか、今日何が起こるか、問題は何かについて全員が話します。 一般的に、多かれ少なかれ普通のスクラム。 スタンドアップでは、チームはペアになります。
カップルは、1匹のように振る舞うポピーのペアの後ろに座っています。 オフィスのすべての車は同じ構成で、ほとんど個人的なものはありません。 多くの開発者は独自のキーボードを使用しますが、それ以外の場合はすべてが一般的です（Zenなど）。 カップルは、トラッカーから最初の無料のストーリー（ユーザーストーリー）を取得し、コードの作成を開始します。 最初に、テストは通常ユニットで書かれますが、多くの場合統合されます。 次に、コードが記述されます。 コードは問題を最小化し、テストに合格する必要があります。 その後、リファクタリングが行われ、恥ずかしくないようになります。 その結果、変更はコードレビューなしで直接コミットされます。 彼らはCIによってピックアップされます（彼らはコンコースの独自の開発とジェンキンスの少しを使用します。 コードがパイプラインを通過しなかった場合、カップルは修正を行います。 すべてが緑色になったら、ストーリーは製品マネージャーに送信され、製品マネージャーはそれを受け入れるか、修正のために戻すことができます。 その結果、変更は、数日ごとに作成されるコンポーネントの次のバージョンに分類されます。 ペアは1〜3日ごとに変更されます。ストーリーの作業がまだ完了していないときに変更が発生する場合があります。 開発者の専門化もありません。たとえば、誰かがOpenStackのみに従事しており、誰かがAWSです-これは原則ではなく、ストーリーは非常にランダムに配信されます。 ある日、Rubyで書いて、明日Goで、CIのシェルスクリプトを編集するか、AWSを構成します。
私はすべてを簡単に説明しようとしましたが、まだ多くのカラフルな詳細がありますが、それらは誰にとってもそれほど興味深いものではなく、特定の質問に答えることができます。 ご覧のように、CFモデルではより深く没入し、意識的に質量を犠牲にする必要があります。 それぞれのアプローチには長所と短所があります。 もちろん、これは週末の戦士にとって、CF開発に参加し、コードを読み、タスクを見つけ、プルリクエストを送信することが不可能であることを意味しません。