他のテクノロジー企業と同様、Lingualeoはいくつかの段階を経ました。
- 製品開発の開始。 開発とデバッグは、プロジェクトに必要なすべてが実行されている単一のサーバーで行われます。 間違いは頻繁に発生しますが、怖くないわけではありません。 これは単なるプロトタイプであり、ライブユーザーはまだいません。
- 最初のユーザーの外観。 会社は生産の間違いや問題の代価を感じ始めます。 実稼働環境ですべてを支配することはすでに不可能です。リリースの際に何を考慮する必要があるかを理解することです。 開発者は、コードベースで動作するワークフローを導入しています。リリースがテストされるステージサーバーのようなものが表示されます。
- プロジェクトとチームの成長。 同時に、多数のタスクが開発中です。 プロセスの要件とコードの品質は大幅に向上しています。 すべてを追跡するのは非常に困難です。誰かが単体テストの実行を忘れ、誰かが次のテストのタスクをどこでどのように展開するかを知りません。
その結果、日常業務に多くの時間がかかり始め、会社はこれらのプロセスを自動化する方法を考えています。
直観的に、Lingualeoチームはすぐに次の段階に進むべき時だと気づきました。 移行は正しい方向に行われることもあれば、そうでないこともありました。 社内のある時点で、1つの共通システムで機能する複数の開発チームが編成されました。 各チームには、jiraに独自のプロジェクト、独自のCIシステム（継続的インテグレーションシステム）があり、ユニットテストの実行、テストサイトの展開、リリースの収集と展開ができました。
かなりいいですね。
それでも、このアプローチには、あまり気に入らない瞬間がありました。
jiraの多数のプロジェクト。 最初は、誰もが1つのワークフローを使用していました。 しかし、その後、1つのチームが追加のフィールドを追加し、もう1つのチームが中間ステータスなどを追加しました。 このため、CIシステムに常に変更を加える必要があり、これらの変更が競合する場合がありました。
自己記述型CIシステム。 彼女はクールで、多くの開発者がいた瞬間まで割り当てられたタスクを完全に解決し、彼らは自由を感じ、積極的に新しいリポジトリを作成し始めました。 システムはこの準備ができていませんでした。 アセンブリは非常に長い時間待たなければならず、ログの表示は最も成功した方法で実装されず、リリースをアセンブルするタスクも一般的なキューでハングしました。
デプロイします。 展開メカニズムは、1つのアプリケーションのみのリリースのために強化されました。 さらに、いくつかのニーズがありました。
次のレトロで、私たちはあなたがもうそのように生きることができないことに気づき、いくつかの点を提案しました：
- すべての開発は、すべてのユーザーに共通のワークフローを使用して、jiraの単一プロジェクトに「移動」する必要があります
- 自作のサーバーではなく、既製のビルドサーバーを使用できます。
- 展開システムは、さまざまなアプリケーションを展開するためにユニバーサルである必要があります
Jiraの単一プロジェクト
新しいワークフローの設計における彼の以前の経験を考慮して、考えられるすべてのタイプのタスクを2つのグループに分けることにしました。
タスク
これらは、コードを記述する必要がなく、最も単純なフローを持つタスクです。
- タスク ただの仕事。 これは、調査、新しいリポジトリの追加、ドキュメントの作成などです。
- 移行 データベースの移行はすべて手動で実行します。 手動では、SQLコンソールで直接行うことを意味しません。これには多くのツールがありますが、手動で開始されます。
Ciユニット
黄色の図は手動で実行する必要があるステップを示し、青色の図は自動化する必要があるステップを示しています
このようなタスクには、いずれかのリポジトリでコードを書く必要があります。 コードを操作するためのフレームワークとしてgitflowを使用するため、分離は次のとおりです。
- 特徴
- 虫
- ホットフィックス
タイプの割り当ては、任意のgitflowの説明に記載されています。 機能とバグを別々のタイプに分けたため、Lingualeoがタスクに優先順位を付けて分析を行う方が便利です。 以前は、各チームに独自のタスクを備えた独自のアジャイルボードがあり、非常に便利でした。タスクをチームに分割する方法を考え出す必要がありました。
また、担当者フィールドを使用する際に小さな問題がありました。一部の移行ではなく、一部の移行中に変更され、時には間違った人に完全に変更されました。 厳格なルールを導入することにしました。名前が担当者フィールドにある場合、その時点でこのタスクを担当します。 以下は、積極的に使用し始めた興味深いフィールドのリストです。
- チーム タスクを所有するチームの名前。
- 成分 この場合、コンポーネントはリポジトリを一意にポイントします。 jiraではコンポーネントフィールドに複数の値を指定できますが、これには問題はありませんでした。
- FixVersion。 タスクが該当するリリース番号。
- 記者 タスクを作成した人。
- お客様。 これがタスクの顧客です。 デフォルトでは、レポーターと同じですが、変更できます。 タスクを受け入れるのは彼です。
- 開発者 タスクを担当する開発者。 タスクには、さまざまな人が行うサブタスクを含めることができますが、タスク全体を担当するのは開発者です。
- QAエンジニア。 開発者との類推により、この人はタスク全体をテストする責任があります。
- コードレビューア。 すべてのタスク（大丈夫、ほぼすべて）がコードレビューに合格し、これがこれを行う人です。
ビルドサーバー
他の皆と同じように、Lingualeoチームはこの市場の3人の主要プレーヤー、Jenkins、Teamcity、Bambooを検討しました。 3つすべてをテストしましたが、Teamcityが一番好きでした。無料で、便利なREST APIと素晴らしいインターフェースがあります。
では、JARVISは誰ですか？
そのため、次の構成を取得しました。jira-タスクの実行、teamcity-テストの実行、リリースのビルドなど、github-コードの保存。 これらすべてのシステムを友達にする必要がありました。
各ペアにはいくつかのプラグインがありますが、それらはすべて非常に便利ではないか、必要な機能を提供していません。 したがって、すべてのシステムを管理する小さなカーネルを作成することにしました。
設計時には、「システムのコンポーネントを簡単かつ最小限の労力で交換する」という要件を考慮しました。 たとえば、ビルドサーバーを置き換えるには、新しいアダプターを作成するだけで、多数のプラグインを探す必要はありません。
JARVISが次の操作を行えるようにしたかったのです。
- コンプライアンスのためのコードをチェック
- 単体テストを実行する
- githubでプルリクエストを作成してマージする
- タスクをテストするためのテストベンチを作成する
- リリースおよびホットフィックスブランチを作成する
- 配備する
さらに、システムのソースコードに可能な限り変更を加えたくないため、プロセスを収集するブロック（アクション）を提供する必要があり、アクションのシーケンスと実行される条件をyaml-の形式で記述することにしました。ファイル。 コード検証を実行するためのルールを説明する構成の例を次に示します。
start inspection: search: jql: 'project="DEV" AND status="Ready for Inspection"' action: type: 'run-build' params: buildTypeId: 'CodeInspection_%component%' success: transition: 'start inspection' fail: transition: 'fail inspection' complete inspection: search: jql: 'project="DEV" and status="On inspection"' action: type: 'check-build' params: buildTypeId: 'CodeInspection_%component%' success: transition: 'complete inspection' fail: transition: 'fail inspection'
最初のルールは、ステータスが検査準備完了のすべてのチケットを検索し、teamcityで対応する構成を起動します。これにより、標準への準拠をコードで確認し、すべての単体テストも実行します。 構成の起動が成功すると、 開始検査遷移がチケットに適用され、 検査中ステータスになります。 2番目のルールは、実行中のすべての構成をチェックします。 正常に完了すると、チケットは続行されます。 ビルド中にエラーが発生した場合、 Fail Inspectionトランジションを介したチケットは開発者に戻ります。
Lingualeoはメインリポジトリだけでなく、すべての内部ライブラリとモバイルアプリケーションにもこのスキームを使用します。 この場合、テストスタンドと展開の作成は、アプリケーションのテストバージョンと製品バージョンのアセンブリに置き換えられます。 新しいリポジトリの追加には数分しかかかりません。そのために、自動コード品質チェック、レビューの作成、ビルドの構築、リリースが行われます。
JARVIS自体もJARVISを使用して開発および構築されています:)
社内の開発プロセスの統一とJARVISの作成により、コードの品質を改善し、本番環境への変更の配信時間を短縮し、開発者が日常業務に費やす時間を短縮することができました。