ワークプロセスの組織について

こんにちは、Habr！
この記事では、1C：エンタープライズプラットフォーム開発プロセスの構築方法、品質保証への取り組み方法、ロシア最大のソフトウェアシステムの作成中に学んだ教訓を共有します。

人とプロセス

最大10人のプログラマからなるいくつかのグループがそれぞれプラットフォームで作業し、その4分の3はC ++で記述され、残りはJavaとJavaScriptで記述されています。
各グループは、たとえば次のような開発の個別の方向に取り組んでいます。

• 開発ツール（コンフィギュレーター）
• Webクライアント
• サーバーインフラストラクチャとフェールオーバークラスター
• など

全部で12を超えるグループがあります。 それとは別に、品質保証チームがあります。
もちろん、このサイズ（1,000万行を超えるコード）のプロジェクトでは、コードの一般的な所有権については言及していません。そのようなボリュームを頭の中に保持することは不可能です。 少なくとも2つのグループで「 バス係数 」を確保しようとしています。
私たちは、柔軟性を提供して開発速度を向上させるチームの独立性と、チームがチームと外の世界との間で効果的にやり取りできるようにする均一性とのバランスを維持しようとします。 そのため、共通のバージョン管理システム、ビルドサーバー、タスクトラッカー（以下で説明します）、C ++コーディング標準、設計ドキュメントテンプレート、ユーザーからのエラー処理ルールなどがあります。 すべてのチームが満たさなければならない規則は、グループリーダーの共通の決定によって開発および採用されます。

一方、「内向き」に向けられたプラクティスでは、チームは非常に自律的です。 たとえば、コード検査はすべてのチームに適用されるようになりました（また、レビューの必須通過を決定する一般的なルールがあります）が、それらは異なる時期に導入され、プロセスは異なるルールに従って構築されました。
プロセスの組織にも同じことが当てはまります。誰かがアジャイルオプションを実践し、誰かが他のスタイルのプロジェクト管理を使用します。 正規のSCRUMはどこにも存在しないようです-箱入り製品の仕様により制限が課せられます。 たとえば、デモンストレーションの素晴らしい実践はそのまま適用することはできません。 他のプラクティス、たとえばプロダクトオーナーの役割には、独自の類似物があります。 プロダクトオーナーとして、グループのトップは通常、彼の指示に従って行動します。 チームの技術的リーダーシップに加えて、その最も重要なタスクの1つは、さらなる開発の方向性を決定することです。 プラットフォームを開発するための戦略と戦術を開発するプロセスは複雑で興味深いトピックであり、別の記事に専念します。

タスクに取り組む

特定の機能を実装する決定が下されると、少なくともタスクを担当する開発者とチームリーダーが参加する一連のディスカッションでその外観が決定されます。 多くの場合、必要な専門知識を持つ他のチームメンバーまたは他のグループの従業員が関与していました。 最終バージョンは、1C：エンタープライズプラットフォーム開発のリーダーによって承認されています。

そのような議論では、決定が下されます。

• タスクのスコープに含まれるものと含まれないもの
• 想定されるユースケース。 サポートしないシナリオを理解することはさらに重要です。
• ユーザーインターフェースはどのように見えるか
• アプリケーション開発者向けのAPIはどのようなものか
• 新しいメカニズムが既存のメカニズムとどのように組み合わされるか
• セキュリティはどうなりますか
• など

さらに、最近、より多くの潜在的な消費者と問題を議論しようとしています-例えば、最後の公開セミナーで、設計中のバイナリデータを操作する新しい可能性について話し、質問に答え、議論からいくつかの可能なアプリケーションを選び出しました以前は考えていませんでした。

新しい関数で作業を開始すると、タスクトラッカーでその関数のタスクが作成されます。 ちなみに、トラッカーは「1C：Enterprise」で記述されており、「Task Base」と呼ばれています。 タスクごとに、タスクドキュメントがタスクトラッカー（実際にはタスクの仕様）に保存されます。 次の3つの主要部分で構成されています。

• 問題の分析と解決策のオプション
• 選択したソリューションの説明
• 技術的な実装の詳細の説明

プロジェクトドキュメントの準備は、実装前に開始することもあれば、タスクに対して何らかの調査またはプロトタイプが最初に行われた場合、後で開始することもあります。 いずれにせよ、これはウォーターフォールモデルとは異なり、反復プロセスであり、プロジェクトドキュメントの開発と改良は実装と並行して行われます。 主なことは、タスクの準備が整うまでに、プロジェクト文書がすべての詳細で承認されたことです。 そして、そのような多くの詳細があります、例えば：

• 使用される用語の統一。 同様の状況でプラットフォームの1箇所で「記録」という用語が使用された場合、「保存」の使用は非常に正当化されるべきです。
• アプローチの統一。 時々、研究と使用の一般的な経験を単純化するために、たとえそれらの不利な点が明らかであったとしても、新しい問題で古いアプローチを繰り返す必要がある
• 互換性。 古い動作を維持できない場合でも、互換性について考える必要があります。 多くの場合、アプリケーションソリューションはエラーが発生しやすく、急激な変化はエンドユーザー側の操作不能につながります。 したがって、多くの場合、古い動作は「互換モード」のままです。 プラットフォームの新しいリリースで起動された既存の構成は、無効にするという意識的な決定が行われるまで「互換モード」を使用します。

さらに、問題の議論は論文の草案に記録されているため、後で特定のオプションが受け入れられたか拒否されたかを理解することができます。
プロジェクトが承認され、開発者がSVNの機能ブランチに新しい機能を実装した後（およびGitで新しいIDEを開発するとき）、タスクはグループの他のメンバーによるコード検査と手動検証を受けます。 さらに、タスクブランチで自動テストが実行されます。以下で説明します。 同じ段階で、別の技術文書が作成されます。これは、テスターとテクニカルライター向けのタスクの説明です。 プロジェクトとは異なり、ドキュメントには技術的な実装の詳細は含まれていませんが、ドキュメントのどのセクションを補足する必要があるか、新しい機能が互換性のない変更をもたらすかどうかなどをすばやく理解できるように構成されています
チェックおよび修正されたタスクはメインリリースブランチに注がれ、テストグループが使用できるようになります。

チュートリアルとレシピ

• プロジェクト文書の価値は、他の文書と同様に、必ずしも明らかではありません。 私たちにとっては、次のとおりです。
  
  • 設計プロセス中、すべての参加者がディスカッションのコンテキストをすばやく復元し、決定が忘れられたり歪められたりしないようにするのに役立ちます。
  • その後、疑わしい状況では、正しい動作がわからないとき、プロジェクトドキュメントは、決定自体とその採用の動機を思い出すのに役立ちます。
  • プロジェクトドキュメントは、ユーザードキュメントの開始点として機能します。 開発者は、ゼロから何かを書いたり、テクニカルライターに口頭で説明したりする必要はありません。すでに準備が整っています。
• 作成された機能を使用するためのシナリオは、一般的なフレーズではなく、常に詳細に記述する必要がありますが、詳細であるほど良いです。 これが行われない場合、使用が不便または不可能になる決定が行われる可能性があり、一部の小さな部分が理由として役立つことがあります。 アジャイル開発では、そのような詳細は次のイテレーションで簡単に修正でき、私たちの場合、ユーザーは数年で修正を取得できます（フルサイクル：プラットフォームの最終バージョンがリリースされるまで->イノベーションを使用した構成がリリースされる->ユーザーからのフィードバックが収集される->修正が行われました->新しいバージョンがリリースされました->修正を考慮して構成が更新されました->ユーザーが構成の新しいバージョンをインストールします）。
• シナリオよりも優れているのは、バージョンの公式リリースと動作の修正の前に実際のユーザー（構成開発者）がプロトタイプを使用することです。 この慣行は、私たちとともに広く使用され始めたばかりであり、ほとんどすべての場合、貴重な知識をもたらしました。 多くの場合、この知識は機能に関連することはできませんが、動作の非機能機能（たとえば、ログの存在やエラーの診断の容易さ）に関連しています。
• 同様に、パフォーマンス基準を事前に定義し、その実装を検証する必要があります。 これらの要件がタスクの完了時にチェックリストに追加されるまで、これは常に行われていませんでした。

品質保証

一般に、「品質」と「品質保証」は非常に広い用語です。 少なくとも、検証と検証という2つのプロセスを区別できます。 検証とは通常、ソフトウェアの動作が仕様に準拠し、他の明らかなエラーがないことを意味し、検証とはユーザーのニーズへの準拠を検証することを意味します。 このセクションでは、検証という意味での品質保証に焦点を当てます。

テスト担当者は、注入後にタスクにアクセスできますが、品質保証プロセスははるかに早く始まります。 最近、私たちはそれを改善するために多大な努力をしなければなりませんでした。 既存のメカニズムが機能の増加と複雑さの大幅な増加に対して不十分であることが明らかになりました。 これらの取り組みは、新バージョン8.3.6に対するパートナーのフィードバックによると、私たちには思えるところではすでに効果を発揮しているが、もちろん多くの仕事がまだ来ている。
既存の品質保証メカニズムは、組織と技術に分けることができます。 後者から始めましょう。

テスト

品質保証メカニズムに関しては、テストはすぐに思い浮かびます。 もちろん、我々もそれらを使用し、いくつかの方法で：

単体テスト

C ++では、単体テストを作成します。 前の記事で述べたように、 Google TestとGoogle Mockの修正バージョンを使用しています。 たとえば、JSONを記述するときにアンパサンド文字（ "＆"）のエスケープをチェックする一般的なテストは次のようになります。

TEST(TestEscaping, EscapeAmpersand) { // Arrange IFileExPtr file = create_instance<ITempFile>(SCOM_CLSIDOF(TempFile)); JSONWriterSettings settings; settings.escapeAmpersand = true; settings.newLineSymbols = eJSONNewLineSymbolsNone; JSONStreamWriter::Ptr writer = create_json_writer(file, &settings); // Act writer->writeStartObject(); writer->writePropertyName(L"_&_Prop"); writer->writeStringValue(L"_&_Value"); writer->writeEndObject(); writer->close(); // Assert std::wstring result = helpers::read_from_file(file); std::wstring expected = std::wstring(L"{\"_\\u0026_Prop\":\"_\\u0026_Value\"}"); ASSERT_EQ(expected, result); } 

統合テスト

次のレベルのテストは、言語「1C：Enterprise」で書かれた統合テストです。 テストの大部分を形成します。 テストの典型的なセットは、* .dtファイルに保存された個別の情報ベースです。 テストインフラストラクチャはこのデータベースをダウンロードし、既知のメソッドを呼び出します。このメソッドは、開発者によって記述された個々のテストを呼び出し、結果をフォーマットしてCI（ 継続的統合 ）インフラストラクチャが解釈できるようにします。

 &  __()   = ("json");  = "__";  = .(); JSON = JSON(); JSON(JSON, ); JSON.(); .(, );  

この場合、記録の結果が標準と異なる場合、例外がスローされ、インフラストラクチャはそれを検出してテストの失敗として解釈します。

CIシステム自体は、32ビットおよび64ビットのWindowsおよびLinuxを含むOSおよびDBMSのさまざまなバージョン、およびMS SQL Server、Oracle、PostgreSQL、IBM DB2、および独自のファイルデータベースからこれらのテストを実行します。

カスタムテストシステム

3番目の最も面倒なタイプのテストは、いわゆる 「カスタムテストシステム。」 テスト対象のスクリプトが1つのデータベースの制限を超えて1Cになった場合、たとえば、Webサービスを介した外部システムとの相互作用をテストする場合に使用されます。 各テストグループには、1つ以上の仮想マシンが割り当てられ、それぞれに特別なエージェントプログラムがインストールされています。 それ以外の場合、テスト開発者は完全な自由を持ち、結果をCIで読み取れるGoogleテスト形式のファイルとして提供するという要件によってのみ制限されます。

たとえば、WebサービスのSOAPクライアントをテストするには、C＃で記述されたサービスを使用し、コンフィギュレーターのさまざまな機能をテストするには、Pythonで記述された膨大なテストフレームワークを使用します。
この自由の裏側は、各OSのテストを手動で構成する必要があること、仮想マシンのフリートを管理すること、およびその他のオーバーヘッドです。 したがって、統合テスト（前のセクションで説明）の開発に伴い、カスタムテストシステムの使用を制限する予定です。

上記のテストは、プラットフォーム開発者自身がC ++で作成するか、特定の機能をテストするために強化された小さな構成（アプリケーションソリューション）を作成することによって作成されます。 これはエラーがないための必要条件ですが、特に1C：Enterpriseプラットフォームなどのシステムでは十分ではありません。ほとんどの機能は適用されず（ユーザーが直接使用します）、アプリケーションプログラムを構築するための基盤として機能します。 したがって、テストには別の段階があります。実際の適用ソリューションに対する自動および手動のシナリオテストです。 このグループには、ストレステストも含まれます。 これは興味深い大きなトピックであり、これについては別の記事を計画しています。

さらに、すべてのタイプのテストがCIで実行されます。 継続的統合サーバーとして、 Jenkinsが使用されます。 執筆時点での外観は次のとおりです。


各ビルド構成（Windows x86およびx64、Linux x86およびx64）には、異なるマシンで並行して実行される独自のアセンブリタスクがあります。 1つの構成のアセンブルには長い時間がかかります-強力な機器であっても、大量のC ++のコンパイルとリンクは簡単な作業ではありません。 さらに、Linux用パッケージ（debおよびrpm）の作成には、結果として同等のコンパイル時間がかかります。
したがって、「短縮ビルド」は1日中機能し、Windows x86およびLinux x64でのコンパイルをチェックし、最小限のテストセットを実行します。定期ビルドは毎晩機能し、すべての構成を収集してすべてのテストを実行します。 アセンブリおよびテスト済みの各夜間アセンブリにはタグが付けられているため、開発者はタスクのブランチを作成するとき、またはメインブランチから変更を挿入するときに、コンパイルおよび作業コピーで作業していることを確認できます。 現在、定期的なビルドがより頻繁に開始され、より多くのテストが含まれるように取り組んでいます。 この作業の最終的な目標は、コミット後2時間以内にテストでエラーを検出することです（テストで検出できる場合）。そのため、見つかったエラーは営業日の終わりまでに修正されます。 このような反応時間は、効率を劇的に向上させます。第1に、開発者自身がエラーの導入中に作業したコンテキストを復元する必要がなく、第2に、エラーが他の人の作業をブロックする可能性が低くなります。

静的および動的分析

しかし、テストだけでは人間は生きていません！ また、長年にわたってその価値を証明してきた静的コード分析も使用しています。 1週間に1回、少なくとも1つの間違いがあり、多くの場合、表面テストではキャッチできないものがあります。
3つの異なるアナライザーを使用します。

• Cppcheck
• PVS-Studio
• Microsoft Visual Studioに組み込まれています

それらはすべて少し異なって機能し、さまざまな種類のエラーを検出し、互いに補完する方法が気に入っています。

静的ツールに加えて、 アドレスサニタイザーツール（CLangプロジェクトの一部）とValgrindを使用して、実行時のシステムの動作を確認します。
操作の原理が非常に異なるこれらの2つのツールは、ほぼ同じ目的で使用されます。たとえば、メモリを使用した誤った操作の状況の検索です。

• 初期化されていないメモリアクセス
• 解放されたメモリアクセス
• 配列の境界を超えて終了するなど。

動的分析では、以前に手動で試行されたエラーが何度か見つかりました。 これは、動的分析を有効にしたテストのいくつかのグループの定期的な自動起動を組織するためのインセンティブとして機能しました。 すべてのテストグループで動的分析を常に使用しても、パフォーマンスの制限はありません-Memory Sanitizerを使用するとパフォーマンスが約3倍低下し、Valgrindを使用すると1〜2桁低下します。 しかし、それらの限定的な使用でさえ良い結果をもたらします。

組織の品質保証

機械によって実行される自動チェックに加えて、品質保証を日々の開発プロセスに統合しようとします。
このために最も広く使用されている方法は、ピアコードレビューです。 私たちの経験が示すように、一定のコード検査は特定のエラーをキャッチするだけでなく（これは定期的に発生します）、より読みやすく、よく組織化されたコードを提供することで発生を防ぎます。 長期的な品質を提供します。
他の目標は、グループ内のプログラマーがお互いの作業を手動でチェックすることで追求されます-タスクに没頭していない人による表面テストでさえ、タスクがトランクに注がれる前であっても、早期にエラーを特定するのに役立ちます。

自分のドッグフードを食べる

しかし、すべての組織的対策の中で最も効果的なのは、Microsoftが「独自のドッグフードを食べる」と呼ばれるアプローチであり、製品開発者が最初のユーザーです。 私たちの場合、「製品」はタスクトラッカー（上記の「タスクベース」）であり、開発者はこれを1日中使用します。 毎日、この構成はCIにアセンブルされたプラットフォームの最新バージョンに転送され、すべての短所と短所はすぐに作成者に影響します。
「タスクのベース」は、数万のタスクとエラーに関する情報を保存する深刻な情報システムであり、ユーザー数は100を超えていることを強調したいと思います。 これは1C：Enterpriseの最大の実装とは比較できませんが、中規模の企業と非常に匹敵します。 もちろん、すべてのメカニズムをこの方法でチェックできるわけではありません（たとえば、アカウンティングサブシステムは一切関与しません）が、テストされた機能の範囲を広げるために、異なる開発グループが異なる接続方法を使用すること、たとえば誰かがWebクライアントを使用する誰かがWindowsのシンクライアントであり、Linuxの誰かです。 さらに、異なる構成（異なるバージョン、異なるOSなど）で動作するタスクベースサーバーのいくつかのインスタンスが使用され、プラットフォームに含まれるメカニズムを使用して互いに同期されます。
タスクベースに加えて、他の「実験的」ベースがありますが、機能的ではなく負荷も少ないです。

学んだ教訓

品質保証システムの開発はさらに続けられ（実際、この道に終止符を打つことはほとんど不可能です）、今、いくつかの結論を共有する準備ができています。

• このように広く広く使用されている製品では、テストを作成するほうが、作成しないよりも安価です。 機能にエラーがあり、それがスキップされる場合-エンドユーザー、パートナー、サポートサービス、さらにはエラーの再現、修正、およびその後の検証に関連する1つの開発部門のコストがはるかに大きくなります。
• 自動テストの作成が難しい場合でも、開発者に手動テストの正式な説明を作成するよう依頼することができます。 それを読んだ後、あなたは開発者が彼の頭脳をどのようにチェックしたか、したがって潜在的なエラーのギャップを見つけることができます。
• CIおよびテスト用のインフラストラクチャを作成することは、財務面でも時間面でもコストのかかるビジネスです。 特に、すでに成熟したプロジェクトでこれを行う必要がある場合。 できるだけ早く始めましょう！

そしてもう1つの結論は、記事から直接ではありませんが、次のことを発表します。フレームワークの最良のテストは、その上に構築されたアプリケーションのテストです。 ただし、1C：Accountingなどの適用ソリューションを使用してプラットフォームをテストする方法については、次のいずれかの記事で説明します。