はじめに：なぜ1CにCI/CDが必要なのか？
1Cプラットフォームを使用している場合は、次の更新後に戦闘ベースで何かが壊れ、変更をすばやくロールバックできない状況に遭遇したことがあるはずです。または、開発チームが1つの構成に取り組んでいて、あるプログラマーのコードが別のプログラマーの変更を上書きする場合。聞き覚えがありますか？
このような問題を解決するために、CI/CD（継続的インテグレーション/継続的デリバリー）があります。これは、ソフトウェアの開発、テスト、および展開のプロセスを自動化する一連のプラクティスです。これらのアプローチは長い間Web開発の標準となっていますが、1Cの世界では人気が高まっています。これは当然のことです。1C エコシステムは特定のものであり、独自の構成フォーマットで動作し、バージョン管理に特別なアプローチを必要とします。
この記事では、ルーチン操作を自動化し、作業をより予測可能で安全にする、シンプルながら効果的な1CのCI/CDパイプラインを構築する方法を説明します。
CI/CDとは簡単に言うと何ですか？
継続的インテグレーションとは、コードのすべての変更が定期的に共通の開発ブランチに統合され、システムがこれらの変更が重要なものを壊していないかどうかを自動的にチェックすることを意味します。構成の変更を保存するたびに、ロボットが自動的に構文チェックを行い、テストを実行し、問題が発生した場合に通知することを想像してみてください。
継続的デリバリーは、コードがテストサーバーまたは本番サーバーへのデプロイメントのために自動的に準備される次のステップです。構成の手動エクスポート、ファイルのコピー、データベースの更新の代わりに、このプロセス全体はボタンを1つ押すだけで、またはあなたの関与なしに自動的に行われます。
考慮すべき1Cの機能
1Cプラットフォームには、通常のWeb開発よりもCI/CDの実装を少し複雑にするいくつかの機能があります。まず、1Cの構成はバイナリファイル（.cf）に保存されており、通常のGitツールではバージョン管理が困難です。第二に、1Cを使用するにはインストールされたプラットフォームが必要であり、これにより自動化された環境の設定が複雑になります。第三に、1Cには、オブジェクトのロック、独占モード、データベース更新の機能など、独自の特性があります。
しかし、これらの問題はすべて解決可能です。XML 形式で構成をアップロードすることができ、これは Git に最適です。1Cプラットフォームは、シンクライアントモードまたはGUIなしで実行できるため、自動化されたスクリプトで使用できます。また、特定のタスクを解決するために、1C にはいくつかのオープンソースツールが作成されており、これについては後で説明します。
自動化ツール
1C の CI/CD パイプラインを構築するには、いくつかのツールが必要です。バージョン管理システムから始めましょう。ここでの選択は明らかです：Git。これは業界標準であり、構成の保存形式を正しく設定すれば、1Cでの作業に最適です。
主要なツールは、1C プラットフォームの外で動作する 1C 言語インタプリタである OneScript です。これにより、使い慣れた言語でスクリプトを作成し、構成に関するさまざまな操作を実行できます。OneScript をベースに、自動テスト用の vanessa-automation や Git との同期用の gitsync などの便利なユーティリティが作成されています。
CI/CDサーバーには、GitLab CI、Jenkins、GitHub Actions、さらにはTeamCityなどの一般的なソリューションを使用できます。選択は、あなたの好みと会社のインフラストラクチャによって異なります。無料のホスティングソリューションを提供し、YAMLファイルを介して簡単に設定できるため、初心者にはGitLab CIまたはGitHub Actionsをお勧めします。
また、コマンドラインから構成を操作するためのツールも必要です。ここでは、1Cプラットフォームの標準機能（/Cモードのコンフィギュレーター）またはv8unpackタイプの特殊ユーティリティを使用して、XMLでコンフィギュレーションを解凍できます。
プロジェクトの基本構造の設定
自動化への最初のステップは、プロジェクトを適切に整理することです。.cfバイナリファイルをGitに保存する代わりに、構成をXML形式でエクスポートする必要があります。これを行うには、プロジェクトのルートに src フォルダーを作成します。このフォルダーには、メタデータオブジェクトごとに個別のXMLファイルとして構成のソースコードがアップロードされます。
Git の典型的な 1C プロジェクトの構造は次のようになります。ルート フォルダーには、アップロードされた構成を含む src ディレクトリ、自動テストを含む tests フォルダー、ビルドと展開のためのサービス スクリプトを含む scripts フォルダー、および CI/CD システムの構成ファイル (.gitlab-ci.yml や .github/workflows/main.yml など) が含まれます。
バージョン管理する必要のないファイルを.gitignoreに追加することが重要です。たとえば、.tmp拡張子の1C一時ファイル、.1CV8ロックファイル、キャッシュとログを含むフォルダーなどです。また、情報ベース自体をリポジトリに保存する必要はありません。構成のソースコードのみを保存します。
最初のパイプラインの作成
コミットごとに基本的なチェックを実行するシンプルなCI/CDパイプラインを作成しましょう。例として、GitLab CI を使用しますが、ロジックは他のシステムにも適用されます。
プロジェクトのルートに.gitlab-ci.ymlファイルを作成し、構文チェック、構成のビルド、テストの実行、デプロイのいくつかのステップを定義します。最初のステップでは、パイプラインは構成の構文をチェックします。これは、閉じていない括弧や間違った変数名などの明らかなエラーをキャッチできる迅速な操作です。
構文を確認するには、コマンドラインモードで1Cコンフィギュレーターを使用できます。XMLファイルから空の情報ベースに構成をロードし、構成チェックを実行するスクリプトを作成します。コンフィギュレーターがエラーを検出した場合、スクリプトはゼロ以外のリターンコードで終了し、パイプラインは停止します。
2番目のステップは、構成のアセンブリです。ここでは、展開に使用できる完全なcfファイルがXMLファイルから収集されます。このファイルはパイプラインアーティファクトとして保存され、次のステップで使用するか、手動でダウンロードできます。
3番目のステップは、自動テストの開始です。Vanessa-Automation または ADD のようなテストフレームワークを使用している場合は、書かれたすべてのテストがここで実行されます。テストは、この段階のために特別に作成され、完了後に削除される一時的な情報ベースで実行されます。
最終段階はデプロイです。このステージは、特定のブランチ（たとえば、masterまたはrelease）に対してのみ実行でき、テストまたは本番データベースを更新します。問題が発生した場合に、以前のバージョンにすばやくロールバックできるように、このステージを実装することが重要です。
テストの自動化
CI/CDの主な価値の1つは、自動テストです。1Cには、自動テストを書くことができるフレームワークがいくつかあります。最も人気があるのは、BDDスタイルのテスト記述（Behavior Driven Development）をサポートするVanessa-Automationです。
BDDテストは、自然言語でGherkin形式で記述されます。つまり、Given、When、Thenです。たとえば、テストは次のようになります。ドキュメント作成フォームを開き、「取引先」フィールドに「有限会社ロガイコピタ」と入力して「保存」ボタンをクリックすると、ドキュメントはエラーなしで保存される必要があります。これらのスクリプトは、プログラマーだけでなく、アナリストやテスターにも理解されます。
このような各シナリオは、アクションを実行し、結果を確認する組み込み 1C 言語での実装に関連付けられます。ドキュメントの実行、レジスタの計算、レポートの生成など、重要なビジネスプロセスをテストでカバーすることが重要です。このようなテストを少し行うだけでも、開発の安定性が大幅に向上します。
ブランチとリリースの戦略
CI/CD を効果的に機能させるには、Git で正しいブランチ戦略が必要です。1C で作業するチームには、簡略化された Git Flow が適しています。メインブランチ master (または main) には、本番環境にデプロイする準備ができている安定したコードが含まれており、develop ブランチは新機能の統合に使用され、タスクごとに個別の機能ブランチが作成されます。
開発者が新しいタスクの作業を開始すると、feature/add-inventory-reportのようなわかりやすい名前でdevelopからブランチを作成します。作業が完了すると、CIパイプラインを自動的に開始するマージリクエスト（またはプルリクエスト）が作成されます。すべてのチェックが成功し、コードレビューが完了した場合、ブランチは開発にマージされます。
開発からリリースを作成するために、最終チェックとバグ修正が実行されるリリースブランチが作成されます。テストが成功すると、リリースブランチがマスターにマージされ、バージョン番号のタグが付けられ、本番システムへのデプロイが自動的に開始されます。
変更の展開とロールバック
1C構成の展開プロセスには独自のニュアンスがあります。ファイルを単に置き換えることはできません。情報ベースを正しく更新し、データ構造の変更を処理し、互換性を確認する必要があります。このプロセスを自動化するために、COM接続または/Cモードでデータベースを更新するスクリプトが使用されます。
更新前にデータベースのバックアップを作成することが非常に重要です。展開スクリプトでは、最初のステップは、タイムスタンプとバージョン番号で保存されるバックアップを作成することです。更新後に問題が発生した場合、このバックアップを使用すると、以前のバージョンにすばやくロールバックできます。
構成を更新した後、スモークテストを実行することをお勧めします。これは、システムの主要な機能のパフォーマンスをすばやくチェックする小さなチェックセットです。たとえば、メインフォームを開いて、簡単なドキュメントを作成し、標準的な計算を実行してみることができます。スモークテストが失敗した場合、展開は失敗と見なされ、自動ロールバックが実行されます。
モニタリングと通知
CI/CD パイプラインの重要な部分は、通知システムです。開発者は、コミットがビルドを壊した場合、またはテストに失敗した場合にすぐに知る必要があります。ほとんどのCI/CDシステムは、Telegram、Slackなどのメッセンジャーや企業システムと統合されています。
通知を設定して、情報を提供するものにし、スパムにならないようにします。たとえば、テストが失敗した場合や本番環境へのデプロイが成功した場合にのみメッセージを送信できます。通知には、どのブランチ、誰がコミットの作成者であるか、どのパイプラインステージが失敗したか、詳細なログへのリンクなどの基本情報が含まれている必要があります。
パイプラインの完全な実行にかかる時間、テストが失敗する頻度、コミットから本番環境へのデプロイまでにかかる時間などのメトリクスを収集することも役立ちます。このデータは、ボトルネックを見つけて開発プロセスを改善するのに役立ちます。
初心者のための実用的なアドバイス
小さなことから始めましょう。すべての可能なチェックを備えた完璧なCI/CDをすぐに構築しようとしないでください。基本的な構文チェックと自動構成のビルドから始めましょう。これが安定して動作したら、いくつかの簡単なテストを追加します。次に、テストサーバーへのデプロイを自動化します。そして、チェーン全体が完了したときにのみ、本番環境への自動デプロイに進みます。
プロセスを文書化します。プロジェクトのルートにREADMEファイルを作成し、CI/CDの仕組み、ローカル開発に必要なコマンド、リリースの作成方法を説明します。これは、チームに複数の開発者がいる場合、またはプロジェクトが別のチームに引き継がれる場合に特に重要です。
失敗したテストを無視しないでください。パイプラインが赤色を示している場合、これは最優先事項であるべきです。「赤」のパイプラインは、テストが失敗した状況を正常化し、時間の経過とともにチームはそれに注意を払わなくなります。ルールは簡単です。テストが失敗した場合は、コードを修正するか、テストを修正する必要がありますが、パイプラインは再び緑色になる必要があります。
チームのトレーニングに時間を割いてください。CI/CDの実装は開発プロセスを変え、すべての開発者がそれに対応できるわけではありません。なぜこれが必要なのか、どのように機能するのかを説明し、例を示すために、いくつかのミーティングを開催してください。数ヶ月間の変化への抵抗に対処するよりも、数時間のトレーニングに費やすことをお勧めします。
典型的な問題とその解決策
一般的な問題の1つは、パイプラインの動作が遅いことです。1C 構成の完全なビルドとテストには数十分かかる場合があります。プロセスを高速化するには、キャッシュを使用します。パイプラインの実行間に、コンパイルされた構成とデータベースを保存します。テストを、常に実行されるクイックスモークテストと、重要なブランチでのみ実行されるテストの完全なセットに分割します。
もう一つの問題は、XML構成ファイルをマージする際の競合です。Git は、特に 2 人の開発者が同じメタデータ オブジェクトを変更した場合、XML 内の競合を常に正しく解決するわけではありません。解決策は、メタデータ構造を理解する gitsync や EDT (1C: Enterprise Development Tools) などの 1C 構成をマージするための特殊なツールを使用することです。
CIサーバーの1Cライセンスで問題が発生することがあります。自動化されたプロセスでは、GUIなしで実行できるライセンスが必要です。ライセンスマネージャーと、構成で利用可能なオプションについて話し合います。代わりに、テスト用のプラットフォームのデモバージョンを使用することもできますが、これには制限があります。
結論
1C の CI/CD を構築するのは簡単ではありませんが、時間を投資することで何倍も利益を得ることができます。自動化により、ルーチンが排除され、エラーが減り、開発プロセスがより予測可能で専門的になります。チームはより頻繁に、より自信を持ってアップデートをリリースでき、コードの品質は必然的に向上します。
シンプルなことから始めましょう。構成を保存するためにGitを設定し、CIに基本的な構文チェックを追加し、最初の自動テストを作成します。新しいチェックを追加し、より多くのプロセスを自動化することで、パイプラインの機能を徐々に拡張します。そして、CI/CDの主な目的は、複雑なテクノロジーではなく、開発の品質と開発者の生活を向上させることであることを忘れないでください。
もっと詳しく知りたいですか？
開発、プロセスの自動化、CI/CD、その他多くのテクノロジーに対する最新のアプローチを学ぶことができます。 コディック. 初心者から経験豊富な専門家まで、あらゆるレベルの開発者向けに実践的なコースを作成しています。
そして、私たちは素晴らしい テレグラムチャンネル 技術的な問題を話し合い、経験を共有し、志を同じくする人々を見つけることができるフレンドリーなコミュニティ。参加してください！ 🚀