125人の開発者のチームでDevOpsを構築する方法

みなさんこんにちは。



私の名前はアレクサンダーチェルニコフです 。私は、ズベルバンクとスベルテクのデジタルコーポレートバンク部門の開発責任者です。



今日、Sberbank Business Online（SBBOL）のDevOpsについてお話します。SBBOLは、大規模なレビュー（1日75 PR）を行うかなり大きなチーム（開発者125人）で構築しました。 現在、プルリクエスト（以降PR）のデバッグされたCD（CI）プロセスは、仕事と私たちの誇りの不可欠な部分です。







それで、私たちは何をしましたか：

1. Bitbucket用の特別なプラグイン「Mega Plugin」を作成しました
2. ジェンキンスと対話するよう彼に教えた
3. いわゆるPrCheck（アセンブリ、セレンテスト、リンター）をねじ込みます

それがどのように始まったかについての詳細。 1つのUIリポジトリーの例について説明します。他のリポジトリーに興味深い機能がある場合は、個別に作成します。

開発者とは何ですか？

むかしむかし、コードレビューで表示されたいくつかの小さなエラーのために、開発は絶えず中断しました。 これらは、JSランタイムエラー、Typescriptコンパイルエラー、グローバルアプリケーションスタイルエラー（ページ全体が「分割」されたとき）などでした。チャットでは、誰もがよく知っている質問が常にありました。 アップグレードできますか？」、「他に開発しないのは誰ですか？ または、私はそのようなものを持っていますか？「そして、他の人。そして、チームは10人でした。そして、計画は9-10人の10-15スクラムチームに成長するために地平線に迫り始めました。



git pre-push hookを使用して安定性の問題を解決しようと考えましたが、このアプローチは2つの理由で機能しませんでした。

1. 安定性は、人的要因がある場所ではありえません。
2. プッシュの前にすべての開発者にプロジェクトの完全なアセンブリを待機させ、リンターやその他のチェックを実行することは無理でした（その後、Seleniumテストはありませんでした）。 さらに、時間の大規模なシンプル。

私たちはPRの段階で障壁に向かって考え始めました。

ジェンキンス作戦は不可能

最初の実装では、ジョブの起動はこのプラグインによって行われました。 つまり 15分（cron）ごとに、彼は新しいコメントでこのプリーズまたは新しいPR をテストし、仕事を始めました。 アセンブリの後、シェルスクリプトでPR（成功/失敗）にコメントを書き込みました。 専門家はコードを見て、その承認を設定しました（厳密に英語を判断しないでください、良い同義語は見つかりませんでした）。



ただし、選択したものだけがコードを挿入できます、ゴッドモード。 通常、アセンブリが成功したことを確認し、「BUILD SUCCESS」を見つけ、アップグレードの回数を数えた後、Mergeボタンをクリックする必要があるのは、リポジトリ上の1人でした。 そして、経験から、それは道徳的に非常に難しいことをお伝えします。 承認があり、「チェック」に合格したように見えますが、とにかくあなたは注ぎ込み、あなたにも責任があります。 誰も3週間以上それを我慢できませんでした。 義務が始まりました:)そして、プロセスの観点から、それはまだ狭い首でした。なぜなら、すべての要件が満たされた後でも、チームはボタンを押す人を見つける必要があるからです。 その結果、1時間から1日、場合によっては数週間にわたって、チームはこの「選択されたもの」を見つけることができず、チーフデベロッパーの隅に隠れていました。



Bitbucketには、アセンブリのステータスを表示する標準オプションがあります。 また、 チェックリストのマージ ：更新の最小数、少なくとも1つのアセンブリの成功、すべてのコメント（チェックマーク）などが許可されます。しかし、これでは十分ではありませんでした。



その後、プラグインのアイデアが生まれたばかりで、彼らはすぐにそれの最小要件を作成し、開発を開始しました。 Bitbucket用に何も書いたことがなく、APIを使用しなかったMaratSadretdinovだけが、1か月後に作業用プロトタイプを提供してくれました（彼は暇なときに書きました）。 最優先事項は要件でした。影響力のあるPRのリストを取得します。 設定した基準：

1. 組み立ては成功しました。
2. 必要な専門家が好転しました（将来、彼らはこれをラベルに結合しました。これについては以下で説明します）。

仕組み：

PRが作成されます>>コメントを書いてテストしてください >>プラグインはMergeボタンをブロックし、githubプラグインはコメントを監視し、Jenkinsでジョブを開始します>> Jenkinsは完了時に成功/失敗を送信します>>すべての基準が成功した場合、プラグインはMergeボタンをアクティブにします>> "神モードユーザー」は、少しずつコードを挿入します。



それだけです デバッグ、バグ修正、JenkinsとBitbucket間の遅延（プラグインがすべてのコメントをスキャンしたため、1秒ごとにすべてのPRを調べるのは困難でした）に1週間または2週間。 そして乾杯！ 壊れた開発についての質問は消えました。



しかし、その後、すべてがさらに面白くなり、開発マネージャーと貪欲な開発者は「脂肪」を望んでいました。

1. test testというフレーズを削除して、自動的に開始しましょう。
2. しかし、ある人がPRを更新した場合、以前のアセンブリをバングし、新しいアセンブリを起動する必要があります。
3. そして、それをどのシーケンスで実行するか、Jenkinsにはすでにキューがあります。そのため、キューの最後に位置しますか？
4. 機械に注ぎましょう！ 手で押さないでください。
5. さまざまなルールに従って、最初は黄色のPRに掛けられたラベルを作成しましょう。 それらがすべて緑色に変わるとすぐに-PRが流れ込みます。
6. Telegramの専門家に、新しいPRを持っているか、2日以上も注がれていない場合などを書いてもらいます。
7. すべてのハードウェアが組み立てられるまで、組み立てを開始しないでください
8. アセンブリが経過したが、非常に長い時間（1週間以上）の場合、つまり 「古い」PR、成功のラベルをリセットする必要があります。

彼らが望んでいたものの多くは、私たちが何になったのかを教えてください。

ラベル

メインラベル-expertから始めましょう。

まず第一に、リリース日、コードの依存性と影響、一般的なアプローチと実践、そしてもちろんコードの書き方を知っているプロジェクトの最も経験豊富な開発者のグループがあります。



チーム 。

チームのラベル。 チームのaruvの最小数を公開しました。 開発者である必要はなく、PRがUIにある場合はjsニックネームである必要はありません。 主な目標は、チームが開発が計画した方向に進んでいることを確認することです。 専門家に先立って同僚にコメントしたのは、経験豊富な開発者かもしれません。



アーチ

コア、共通コンポーネント、ユーティリティが変更されたときに、このようなラベルを思いつきました。 このようなPRは通常、非常に多くのフォームとページに影響を与え、機能を著しく損なう可能性があります。 プロジェクトの通常の通常の構造（フォルダーsrc / Core、src / Commonなど）によって決定されました



prCheck

最も重要な技術ラベル。 信頼性の保証。 UIリポジトリでは、これらはtslint、lesslint、jsonlint、typescript、webpackであり、かつてはグルーヴィーなe2eテストでもあります。 バック-コンパイル、統合テストAPI。 すべてがドッカーです。



oracle 、 security 、 admin 、 devops

各分野の高度な専門家。



ソナー

これはソナーです。 コードをスキャンし、プロジェクトで採用したルールでタスクを開始します。



predvnedrezh

インプラントが鼻の上にあるとき（1週間または2週間）の「事前判断」の時間の特別なラベルで、何も注ぐことはできません。 そして、私たちは何も注ぎません。 ほぼ。 さて、あなたは理解しています;）



not_task、not_story、not_bug、not_test

Jiraからの挨拶付きのラベル。 PRは常にJiraからのタスクと接続しています。これは、タスク番号を指定せずにコミットを実行できないためです（サーバー上の多くの人がこのようなgitフックを設定していると思います）。 プラグインは、単にJiraのタスクのタイプを調べます。 したがって、このラベルは、コードがあなたが期待するものではなく、他の何かによって支配されていると言います。



css

PRにはスタイルファイルがあり、スタイル、レイアウト、デザインの達人が必要だと彼は言います。



この場所はあなたのラベルかもしれません



また、ラベルを手動で追加する可能性も認識しました（一部の規則を規制できない場合）。PRの作成者または専門家自身が、より多くの専門家（さらに多くの専門家！）を追加できます。



ラベルはオプションにすることもできます;マージボタンをブロックしません。

デフォルトのレビュー担当者

プラグインのもう1つの興味深いスキルは、自動的にエキスパートを任命することです。 プラグインの前に、各開発者は、専門家、チームメイト、および関心が対応するラベルによって影響を受けた他の人を配置しました。 最初はロシアのルーレットで、中に小さなカウンターがありました。 少なくとも2人の専門家による評価のルールがリポジトリで機能する場合、すべてから3人の専門家が選択されます。



あなたは、なぜPRの専門家を2人か3人選ぶのかと尋ねるでしょう リスト全体をすべてのPRに割り当ててみませんか？ 誰ができる-彼は見ます。 しかし、彼らが言うように、「一般は誰も意味しない」。 ビットパックには通知付きのベルがあり、1日あたり50のPRがある場合、各エキスパート（たとえば10人）はこのカウンターを常にゼロに「駆動」する必要がありました。 （専門家もコードを書くことを考えると）ほとんど不可能でしたが、チームの士気低下についての疑問が再び生じました。 プラグインは私たちすべてを救った。



次に、専門家（休暇、病気）を無効にする機能、および個人の勤務スケジュールの導入を追加しました。 一部のチームと専門家は他の都市に座っています。 しかし、プラグインがこれを考慮に入れなかった場合、午前5時にMSCがPRを作成し、10のMSCに来た2人のMuscovitesが割り当てられたことが判明しました。 このPRをすぐに見ることができる専門家はいましたが。

aprovsの優先順位またはネポティズムへの対処方法

サーバーリポジトリの1つで、彼らはapruvの優先順位（または重み）のようなローションを望んでいました。 これは何ですか



チームにいる専門家（マリオなど）がいます（任天堂など）。 同僚がPRを公開し、マリオが一度に2つのラベルを根こそぎにし、緑化します-nintendo_teamとエキスパート。 彼は専門家です。 このコードを担当していますが、まだ疑いがあります。 私たちはリポジトリを気にしないことに決めましたが、別のものにしたいと思いました。 チームラベルの優先度が高くなるため、このチームのエキスパートはグリーンエキスパートになれません。 おもしろいですが、チーム（いくつかの2つの任天堂とデンディのチーム）間のネポティズムの問題は解決していませんでした:)または多分それは…

依存プルリクエストのクラブ

私たちだけでなく、そのようなニーズもあります。たとえば、同時に新しいAPIを編集し、すでに新しいコードでアプリケーション全体をチェックするなど、依存するPRをUIとBackにすぐに配置する必要があります。 これを行うために、プラグインの「従属PRとそれらの同時影響」の改訂版を思いつきました。 PRでは、必要な別のリポジトリにPRのリンクを配置すると、ブランチと依存PRブランチから同時にアセンブリがアセンブルされます。 APIモデルをクライアント+サーバーに同時に変更すると、非常に役立ちます。たとえば、

// Dog: {age: number, id: string} // Dog: {age: string, guid: string}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

または、1つのリポジトリでテストを編集する場合、ブラウザでフレーズを含むボタンを探します

 @FindBy("//button[text()=""]") class MyButton
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

UIコードでは以前と同じです：

 <button></button>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その後、2つのリポジトリで再度編集する必要があります。

さまざまなコマンドボタン

問題が発生した場合にチェックを再開する[再起動]ボタンがあります。

すべてのラベルを破棄して再計算する必要がある場合は、[再計算]、[リサイクル]ボタンがあります。

文句を言うのが好きな人のために「あまりにも長いレビュー」ボタンがあります。 「どこへ」メッセージが送信されます。 おそらくすぐに、「専門家の変更」、「50ルーブルの寄付」などの重要で興味深いボタンを追加します。



おそらくこれが私が特に共有したいと思ったすべてです。 ああ、私はほとんど忘れていました。 プラグイン管理パネルはまだあります。



質問を書いてくれてありがとう。 私たちの興味深い経験があなたの仕事に役立つことを願っています。