1Cだけでなく、CROCの統合開発スタンド

大規模で複雑なプロジェクトで蓄積された開発経験は、開発プロセスを充実させる必要のある有用なツールとエンジニアリングの実践に組み込まれ、それをもう一度考え直します。 獲得した経験の価値を成果物として認識し、開発したいという欲求が、現在のプロセスにツールとプラクティスを実装する必要性を理解するようになりました。 また、ソリューションの設計および開発プロセス全体に対するアプローチの抜本的なレビューを開始しました。 1Cの世界でのチーム開発に対する「古典的な」アプローチの典型的な制限と欠点を説明する意味はありません。 このトピックについてはすでに多くのことが述べられています。 これらの欠点を小さくし、ほとんど怖くないようにしたパターンのみを説明します。



だから、 統合開発スタンドを知ってください！

アーキテクチャの一般原則

スタンドのアーキテクチャを設計し、プロジェクトに実装されたソリューションのライフサイクル全体をカバーし、獲得した経験を実装し、プロセスを標準化し、ルーチンを自動化しようとしました。 同時に、サービス、開発、およびユーザーエクスペリエンスの観点から、拡張性と最大限のシンプルさを維持するために、開発の可能性を引き出す必要がありました。 実際に効果的であることが証明されたツールと技術をプロセスに追加する必要があります。 そして、役に立たないすべての作業を削除する必要があります。

プロセス

ソリューションのライフサイクルは、プロジェクトの規模と複雑さに応じて実質的に変化しません。 分析、設計、開発、テスト、実装、保守、廃止措置が含まれます。 最大の効率を得るには、これらの各プロセスを検証して、前後のプロセスと調整し、無制限の数のプロジェクトで複製できる自動化されたコンベアのように組み合わせる必要があります。 タスクは、クラウドサービスと企業のローカルネットワークの両方に展開できる、分離されたコンテナ内のエクスポートされたAPIを介して接続されたマイクロサービスの形でシステムを実装することで解決されました。



これは、プロセスを実装するスタックの外観です。





クローズドソースコードを使用した有料サービスの使用を最小限に抑えようとしましたが、これは所有コストにプラスの影響を及ぼしました。 ほとんどすべてのサービスはオープンソースであり、Linux上で実行されます。



このプロセスは、開発チームの各メンバーを最大限に活用できるように設計されており、標準化と自動化により、過度の複雑さとルーチンが排除されます。

設計（アプリケーション設計サービス）

プロジェクトの開始時の最も重要な段階の1つは、要件の分析に基づいて将来のソリューションを設計することです。 主なタスクは、開発者/エンジニアとコンサルタントの両方が理解できる用語で、最も理解しやすく、明確かつ迅速な方法で、将来のソリューションのアーキテクチャを説明することです。 メタデータ、実装されたビジネスプロセスのアルゴリズムを説明します。 同時に、入力データに適応できる特定の条件にすばやく適応できる既製のテンプレートを最大限に活用し、出力でプロジェクトのドキュメントを取得したいと考えました。



「1C：DSS」構成を適用ソリューションの設計用の単一インターフェースとして実装し、ビジネスプロセスと機能を記述する概念と、TP（FDR）を設計する概念を大幅に作り直しました。 また、1C：DO機能とdocx形式のドキュメントを生成するためのマイクロサービスとの統合により、ドキュメント生成のプロセスを自動化しました。



「1C：DPR」。 プロジェクト情報の編集：





「1C：DPR」。 プロセスレポート：





「1C：DPR」。 オブジェクトメタデータの編集：





「1C：DPR」。 ビジネスプロセス図の編集：





ところで、システム内のビジネスプロセスとオブジェクトの関係を視覚化し、登録済みの要件に基づいて改善点のリストを作成し、プロジェクトのドキュメントを自動的に受け取ることができます。 そのため、開発プロセスを詳細に計画し、複雑さ、タスクの接続性を確認し、実装のタイミングと手順をより正確に決定します。



もちろん、設計プロセスが劇的に変わったとは言えませんが、組織的なアプローチの統一と多くの機能の自動化は、プロジェクトの品質にすでに貢献しています。

開発（継続的な統合、検査、テストサービス）

CROCで確立された標準への準拠を保証するために、開発したコードの包括的で継続的な自動品質管理の可能性に焦点を当てました。 さらに、たとえサードパーティの開発チームを引き付けたとしても、その方法、ツール、および開発標準は、当社が採用したものとは大幅に異なる可能性があります。



スタンドでは、各開発者のコ​​ミットにより、Gitsyncサービスを介して構成をディレクトリおよびファイル構造に解析する手順が自動的に開始されます。 結果の変更はインデックス化され、Gitリポジトリに配置されます。 私たちの場合、これはGitlabサービスです。 変更が構成リポジトリに投稿されたときに入力されたコメントテキストからコミットメッセージが自動的に生成され、バージョン管理システムのコミットの作成者が構成リポジトリのユーザーにマッピングされます。 コメントテキストからの解析中に、開発タスクと人件費に関する情報を取得し、それをJiraなどのタスク追跡システムに渡すことができます。 これにより、開発履歴の包括的な全体像が得られます。 たとえば、コード行で作成者を見つけることができ、コミットに関するスマートコメントを使用すると、タスクのステータスを自動的に制御し、タスク自体で直接タスクに関連するコードを評価できます。



Gitlab これで、コミットによって配置されたコードの任意の行にコメントを追加できます。





Gitlab 構文を強調して「コードレビュー」を実施します。





Gitlab 新しいコミットのコード変更の明確な画像を取得します。





各コミット後、SonarQubeサービスによる静的コード検査の手順がリポジトリで自動的に開始されます。 BSLコミットコードは、コード開発標準を記述する一連のルール（品質プロファイル）に準拠しているかどうかがチェックされます。 この手順は、開発中の構成のコードと、外部メカニズム（拡張機能、外部レポートおよびプロセス、および原則として、他の言語であっても他のプロジェクトコード）の両方に対して実行されます。



SonarQube：





各チェックは、次のような追跡されたコードベースの品質メトリックの情報を更新します。

• 技術的負債-特定されたエラーを修正するために必要な総労働力。
• 品質のしきい値-エラー、脆弱性、およびコードのその他の欠点の最大許容インジケータ。これに達すると、リリースのリリースは不可能と見なされます。
• コードの重複-開発された構成のフレームワーク内で何度も繰り返されるコードの行数。
• 循環的および認知の複雑さ-コードのサポートと洗練を複雑にする多数のブランチを持つアルゴリズム。

検証の結果として収集されたメトリックは、プロジェクトのコードベースの現在の状態を視覚的に表現し、品質の評価、リスクの特定、エラーの迅速な修正を可能にします。



品質プロファイルは、XPathを介した独自のルールセットで拡張できます。また、1Cプラグインの独自の実装の一部として新しいルールがリリースされたためです。 これにより、特定のソリューションの現実に基づいて、品質要件を柔軟に管理できます。



構成解析プロセスの自動起動、コード検査、自動テストなど。 Continuous Integration Service（Jenkins Service）を起動します。 このような組立ラインの数と性質は、プロジェクトの仕様に応じて変更できます。



説明されているプロセスは比較的複雑ですが、ルーチンを実行するすべてのコンベヤメカニズムはクラウドサービスに隠されています。 また、開発者はコンフィギュレーターの使い慣れたインターフェイスを扱い、より高度なツールを使用してスキルを開発することもできます。 たとえば、サードパーティのコードエディタやSonarLint、SourceTreeなどと連携した外部メカニズムのリポジトリであるgit。





一般的な場合、開発者は情報ベースを1C構成保管サービスに接続し、コードを記述してこのサービスに配置することにより、スタンドで隠されたプロセスを起動します。 コミットをチェックした結果、コードで欠点が特定された場合、開発者は、エラーの説明へのリンク、およびSonarQubeサービスインターフェイスでの人件費の修正と一時的評価の推奨事項へのリンクを含む電子メール通知（またはチャットボットメッセージ）を受け取ります。 エラーを修正した後、新しいコミットが発生し、プロセスが繰り返され、編集されたタスクが自動的に終了します...技術的な負債が減少します。 同じロジックで、自動テストプロセスが構築され、各コミットがテスト環境の展開の開始を開始し、テストライブラリから必要なテストを接続します。 実行後、テスト中のエラーに関する情報と、テストでのコードカバレッジに関する情報が集約されます。



継続的かつ包括的なコード検証の効果を過大評価することは困難であり、開発された機能の自動テストがそれに続きます。 これにより、広範囲にわたる結果を取り除き、開発段階を透明にし、適切に構築されたプロセスと組み合わせて、開発者の資格を客観的に評価し、請負業者に依存するリスクを排除できます。 現在のコードベースのパラメーターを推定することで、新たなリスクを迅速に特定して軽減し、設計上の欠陥を修正し、変化する要件にタイムリーに対応できます。



スタンドアーキテクチャのモジュール構成により、プロセスに新しいモジュールを埋め込み、必要なプロジェクト数に合わせてソリューションを複製できます。 概略的には、次のようになります。

テスト（継続的なテストサービス）

開発プロセスのパイプラインに統合されている継続的なテストサービスについては既に説明しました。 現時点では、煙テストと単体テストのテスト実行がスタンドで実施されています。 自動テストの機能は、xUnitFor1Cフレームワークを使用して実装されます。



テストプロセスの開始とコード検査は、プロジェクトリポジトリのコミットイベントに関連付けられています。 単体テストの場合、機能の開発と並行してテストを開発することを意味します。 実装の直前に、準備されたテスト情報ベースに最新の構成が自動的に展開されます。 次に、クライアントが起動され、既に実装されている機能のテストスクリプトが実行されます。 自動テストサービスとBSL SonarQubeプラグインの緊密な統合により、テストでのコードカバレッジなどのパラメーターを計算できます。 テスト実行結果は、ReportPortalテスト分析および視覚化システムにアップロードされるレポートです。 このサービスは、テスト実行に関するデータ（統計と結果）が集計され、転倒の分類に関するシステムの基本的なトレーニングが行われ、さらに原因がさらに自動的に判断されるレポートポータルです。 テスト実行のすべてのパラメーターは、グラフ、チャート（ウィジェット）用のさまざまなボードを備えた便利なWebインターフェイスで使用できます。 ポータルの機能を拡張するには、独自の拡張機能を使用できます。



自動化されたテストサービスは、以前に実装された機能を破壊したり、エラーが発生したりするリリースコードに侵入するリスクを減らす別のステップです。



ReportPortal。 ダッシュボード：









ReportPortal。 失敗したテストの実行：





ReportPortal。 欠陥の種類：





ReportPortal。 欠陥タイプの編集：

開発

実行された作業の結果を評価すると、すでに実装されている計画から、どのアイデアがすでに正常に機能しており、まだ実装されていないかがわかります。



近い将来の計画のうち、ブースの開発は、ブースサービス管理ポータルの作成です。 ポータルのWebインターフェースを使用すると、プロジェクトをスタンドに接続するためのアプリケーション、サービスコストの計算機、およびプロジェクトのリクエストに応じた自動展開を使用できます。 その結果、マネージャーは選択したサービスのコストの計算をすぐに取得し、コストを見積もり、プロジェクトの開発者を決定できます。



1Cシステムを運用するために、ポータルをクラウドソリューションと統合する予定です。 これにより、スタンドに実装された開発サービスと合わせて複製された標準ソリューションを迅速に展開し、顧客システムをより効率的にCROCクラウドに移行できます。



また、管理ポータルを自動構成管理サービス（展開、構成、削除）と統合することも計画しています。 これにより、展開時間が短縮され、システムのセットアップとメンテナンスが簡素化されます。 また、セキュリティのレベルを上げるために、すべてのサービスで同じアカウントを使用するために、スタンドのすべてのサービスにパススルー認証サービスを導入します。



ソリューション開発のフルサイクルの履歴の観点からプロセス全体を考慮すると、作成されたパイプラインにより、プロジェクトの成果物とそれに参加した専門家の両方によって、多数のさまざまなメトリックを収集して集約することができます。 このような詳細なレトロスペクティブは、複雑な問題を解決する際の経験の蓄積と再利用に貢献し、より効率的で調整された作業のために成功した開発者のチームを形成します。



UPD。 コメントのリクエストで、私たちが使用しているオープンソース製品のリストとリンクを追加します。

製品	ベンダー/著者	参考文献1	参照番号2
1C	1C	http://v8.1c.ru
1C：DSS	1C	http://v8.1c.ru/model/
1C：TO	1C	http://v8.1c.ru/doc8/
Git	Sfc	https://ru.wikipedia.org/wiki/Git
Gitlab	Gitlab	https://ru.wikipedia.org/wiki/GitLab	https://about.gitlab.com/
ジラ	アトラシアン	https://ru.wikipedia.org/wiki/Jira	https://en.atlassian.com/software/jira
レポートポータル	EPAM Systems、Inc.	https://github.com/reportportal	https://rp.epam.com/ui/
ソナークベ	ソナーソース	https://ru.wikipedia.org/wiki/SonarQube	https://github.com/SonarSource/sonarqube
ジェンキンス	川口康介	https://ru.wikipedia.org/wiki/Jenkins	https://github.com/jenkinsci
ソースツリー	アトラシアン	https://www.sourcetreeapp.com/
xUnitFor1C	アートベア	https://github.com/xDrivenDevelopment/xUnitFor1C	https://github.com/artbear
Gitsync	エビルビーバー	https://github.com/oscript-library/gitsync	https://github.com/EvilBeaver
SonarQube 1C（BSL）プラグイン	銀の弾丸	https://silverbulleters.org/sonarqube	https://github.com/silverbulleters/sonar-1c-bsl-public