🍛 🐥 🤱🏾 Slackの良いボット 🛌🏻 🌌 🧑🏿‍🤝‍🧑🏿

この記事では、リリース用のボットについて説明します。マイクロサービスバックエンド（a）からwin 10のアプリケーションに至るまで、非常にさまざまなプロジェクトがあります。

誰もが製品に何かを展開したいので、このプロセスを何らかの方法で管理し、システムの重要な部分が同時にリリースされるのを防ぐ必要があります。また、すべてのリリースの詳細なログを保持する必要があります。この場合、イベントのシーケンスを復元し、悪影響をもたらすリリースを見つけることができます。

それはすべて、そのような魂の叫びから始まりました：

「 開発者の数は増え続け、会社は発展しており、アンロードプロセスはますます複雑で複雑になっています。「善」のキューは蓄積されています。彼がまだ「良い」を受け取っていない場合、定期的に善意者を蹴ります。良いを求めるメッセージはチャットルームで失われますが、たとえば、明日、他の誰かがつかむと 前のタグがアンロードされていないことを確認しないでください=>自分に気付かれずに2つをアンロードします-そしてすべてが壊れます。

Slackの特別なチャットルームで誰がいつアンロードするかという問題をかなり長い間解決しました。リリースをアンロードするには、このアクションに「良い」を要求する必要がありました。その後、「ウェルウィッシャー」の1人が、タスクのすべての兆候をチェックしました。

コードのレビューでした
QAからのコメントはありますか
お客様はテストベンチで結果を確認しましたか
荷降ろしのドキュメントはありますか
リリースが失敗した場合にロールバックする方法に関するドキュメントはありますか
など

その後、有力者はこのリリースの可能性をすぐに評価しました。たとえば、ネットワーク担当者がDCのいずれかで作業していて接続を切断している場合、バックエンドに何かをアップロードすることは強くお勧めしません（もちろん、正しく動作するはずですが、なぜ運命を誘います）。「良い」が受け取られたら、ドキュメントに従ってリリースに進むことができます。原則として、どのバックエンドリリースでも、マジックスイッチをプルする管理者が必要であり、タスクに応じてコードがサーバーに配置されます。データベースの構造は変更できますが、一般には多くの変更が可能です。ボタンをクリックするだけでリリースされるものもあれば、複雑なデータベースの移行、キャッシュのクリアなどのいくつかのスクリプトを実行してリリースされるものもあります。その後、管理者はzabbixのチャートを監視し、開発者はログの内容を見て、ロールバックする必要のない機能を確認します。

時間が経つにつれて、同期チャットの情報量は膨大になり、現在何が起こっているのかを理解することはほとんど不可能になりました。そして、リリースプロセスを体系化したボットを作成することにしました。

ボットのタスクは次のように設定されました。

仕事の兆候を確認する
リリース要求キューを管理する
管理リソースを管理する
リリースのステータスのすべての変更について、リリースの開始者に通知する
会社のリリースアクションの完全なログを保持する
アップロードが成功した後にバグトラッカーのチケットステータスを変更する

数週間後、私たちはドブロボットを手に入れ、彼にチームを教え始めました。

アップロード許可のリクエスト

@dobrobot dobro #<    > @dobrobot dobro <  wiki    > @dobrobot dobro <  ( )>

リリースに管理者が不要な場合、たとえば、iOSアプリケーションの新しいバージョンをAppStoreに送信する場合、no_need_adminパラメーターがdobroコマンドで指定されます

リリースイニシエーターがdobroコマンドをボットに送信すると、リリースチャットに次のメッセージが表示されます。