AS / 400は多くのロシアの大手銀行で使用されており、それらはすべてCI / CDの方向にゆっくりと動いています。 Raiffeisenbankは、これらのプラクティスを使用して商業運用でAS / 400プラットフォームにソフトウェアをインストールした最初の（最初ではないにしても）の1つです。
なぜ私たちはこれに来たのですか
私たちは長い間、プラントの自動化に取り組んでいましたが、これにはさまざまな理由がありました。
- インストール期間。 このため、銀行の顧客はこの製品を長期間利用できず、勤務中の夜間シフトの従業員にはすでに定期的なメンテナンスで忙しいにもかかわらず、追加の負担があります。
- インストールの品質。 インストール用に準備されたオブジェクトを手動で転送すると、何かが「突然」消えたり、逆に表示されたりする場合があります。 可変オブジェクトのバックアップは完全に義務付けられており、古いオブジェクトを保存せずに、パッケージオブジェクトの1つの新しいバージョンを誤ってインストールする可能性があります。 これが何につながるか、私たちは皆非常によく知っています。
いくつかのインストールが失敗した後、AS / 400のインストールに特別なインストーラーを含めることにしました。 特定の配信ごとに、開発者はCLスクリプトを準備しました。 彼は、配信の完全性、可変オブジェクトのバックアップの可用性、オブジェクトへの正しい許可のインストールを確認し、ソフトウェアをインストールし、緊急事態に対処しました。
インストールチームの安定性が向上したため、サポートチームとビジネスは新しいアプローチを気に入っていました。 しかし、開発者にとっては、 「xxxオブジェクトを取得し、別の環境に移動し、yyyに配置し、標準認証を追加する」といった単純な指示の代わりに、インストールごとに追加のプログラムを作成する必要があったため、より困難になりました。
一部の問題は未解決のままでした。 テストされたソフトウェアは、生産性の高いものと必ずしも一致しませんでした。 開発者は、システムの正しい操作に関するビジョンに基づいて、準備されたプログラムの最後の瞬間をいつでも変更できました。 これは、産業開発環境で災害を引き起こす可能性があります。
さらに、供給を段階間で移動するのに常に多くの時間がかかりました。 コードを書いた後、開発者はテスターに尋ねました：「どこに何かを置きますか？」。 しばらくして、テスターはタスクに答えて開発者に転送しました。 彼はタスクをインストールして送り返しました。 その後、発見された欠陥を修正するときに、「ボールを投げる」ことは、戦闘に入るための配達の準備として始まりました。 最良の場合、最悪の日には、そのような移行ごとに数分かかりました。
サポートサービスにとって、生産オブジェクトが最後に変更された目的、システムを以前のバージョンにロールバックする方法、変更がインストールされた非工業環境、およびその構成要素を理解することは非常に重要でした。
新しいAS / 400ツール
銀行でのCI / CDおよびDevOpsの動きの出現により、新しいツールを受け取り、すぐにそれらを習得し始めました。
ソースコードは適切なリポジトリ（Git（Bitbucket）、収集された配信-Artifactory、およびアセンブリ、インストール、テストプロセス-Bamboo）に移動されました。
RPG / C / CLのソースコードが単なるテキストであるため、コードリポジトリに多少スムーズになった場合、AS / 400用の標準Bambooプラグインがないため、アセンブリおよびインストールオーケストラ（Bamboo）をいじる必要がありました。
さまざまなインストールオプションを試し始めました。 「追加のコードなしで、インストールおよびアセンブリロジック全体をftp / sshスクリプトとしてBambooに保存します」で始まり、 「AS / 400でユニバーサルインストーラーを作成します」で始まります。
その結果、他のプラットフォームのCI / CDプロセスと実質的に変わらないプロセスが得られました。
プロセスの中心的なリンクはJiraです。Jiraは、要件、ドキュメント、コミット、ビルド、およびインストールに関するすべての情報を収集します。
Jiraタスクの形式で表示されるすべての要件は、ソフトウェアを使用するための要件とシナリオを見つけて説明するアナリストの仕事に入ります。その後、開発者がタスクを取得します。
開発者はコードを記述し、Bitbucketで公開します。 コミット識別子とそのリンクが自動的にJiraタスクに表示されます。
Bitbucketのコミットにより、Bambooでアプリケーションの構築が自動的に開始され、組み立てられた配信がArtifactoryに公開されます。
アセンブリが正常に完了すると、開発者のサンドボックスでソフトウェアインストール計画が開始され、そこで開発者が何を行ったかを確認できます。 また、インストールが正常に完了すると、一連の自動テストが開始され、新しい配信の品質について開発者に通知されます。 インストールのステータスに関する情報は、JiraタスクとBitbucketの両方にすぐに反映されます。
欠陥がない場合、開発者は次のタスクに進むことができます。
次に、テスターがプロセスに含まれます。テスターはテスト用のソフトウェアをインストールする場所を決定し、ボタンを押してソフトウェアを配置します。
テストが完了すると、変更を検証して同意するサポートスペシャリスト向けの「変更要求」が作成されます。 その後、適切なタイミングでアテンダントがボタンを押してBambooにインストールします。
ちなみに、以前の記事の1つで、長期にわたる利用不能に敏感で、1日あたり何百万ものリクエストを処理するアプリケーションについて書いています。 上記のプロセスによってのみ産業環境に入ります。
ここで、AS / 400でのアセンブリとインストールの詳細を少し詳しく説明します。
組立
残念ながら、RPG / CLプログラムは* nixまたはWindowsマシンでコンパイルできないため、標準のソフトウェアアセンブリスキームを少し複雑にする必要がありました。
私たち自身のために、Bambooエージェントがリモートコンパイルを行う「参照」AS / 400環境をすぐに特定しました。
新しいソフトウェアを作成する開発者は、将来どのようにアセンブルおよびインストールされるかについて事前に注意します。 このため、Bambooの各ソフトウェアには独自のビルドおよびデプロイスクリプトがあります。
コミット後、Bambooのアプリケーションのビルドプランが自動的に起動され、特定のリポジトリ用に構成されます。
ソースコードがビルドエージェントにアップロードされてホストされ、次にFTPがAS / 400の一時ビルドライブラリに配置されます。 次に、sshを使用して、アプリケーションビルダーがコンパイルされ、呼び出されます。 コレクターのタスクは、すべてのプログラムとインストーラーをコンパイルし、それらを1つのパッケージに入れて、あらゆる環境で展開できるようにすることです。
通常のソフトウェアパッケージ、インストール準備完了：
完成したFTPパッケージは、AS / 400からビルドエージェントに転送されます。
プログラムの変更は変更の一部に過ぎず、2番目はデータベースを変更するスクリプトであることに注意してください。 彼らはBitbucketからビルドエージェントに移動し、別のアーティファクトとして既にアセンブルされたAS / 400ソフトウェアパッケージに参加します。
ビルドが完了すると、アーティファクトがBamboo and Artifactoryで公開されます。
Bambooのアセンブリプランは、銀行で作成されたAS / 400ソフトウェアに適用できるように設計されています。 新しいプランを追加するには、15分かかります。他のプランの複製といくつかの変数の値の変更を考慮に入れます。
設置
当社のインストールプロセスの主な利点の1つは、それが産業環境であろうと開発環境であろうと、どのような環境でも再現性があり、同じであることです。 開発環境でのインストールの段階で、本稼働環境でインストールのテストを開始します。
一般的に、インストールは次のようになります。
ボタンをトリガーするかボタンを押すと、指定された環境のBambooで展開計画が開始されます。 まず、Artifactoryからインストールエージェントにアーティファクトが送り込まれます。これらはLiquibaseスクリプトとインストールパッケージ（保存ファイル）です。
次に、保存ファイルオブジェクトがFTP経由で転送され、プログラムがインストールされる環境のAS / 400の一時ライブラリに解凍されます。 次に、Liquibaseユーティリティが起動され、jt400ライブラリを使用してAS / 400に接続し、データベース更新スクリプトを実行して、変更ログに対応するエントリを記録します。
最後に、sshを介したBambooはインストーラーを呼び出します。インストーラーは、可変オブジェクトをバックアップし、配信の内容をチェックし、変更を加えて承認を修正します。
インストール結果は、ニュースレターを購読しているチームのすべてのメンバーに送信されます。
小さな便利な機能を追加しました。プログラムレベルで更新されたソフトウェアのバージョンには、最後の変更が行われたタスク番号とBitbucketのコミットIDがマークされています。
これにより、最新の変更をすばやく見つけて、コードの変更を確認できます。 緊急の状況では、サポートサービスでさえ、ソフトウェアのコンパイル、ビルド、インストールに関する貴重な知識がなくても、コードに小さな変更を加えて製品にパッチを送信できます。
現在、1日あたりAS / 400環境で約150のインストールを実行しています。 私たちは絶えずプロセスを改善しています、それは石切りではなく、標準と手順に固定されていません-それは生きて発展します。 開発者はますます好みを感じ、新しいアイデアを持ち、新しい改善を提供しています。 サポートは、これらのアイデアを実現すると同時に、独自の変更を提案しようとしています。 これらのツールとプロセスは、ソフトウェアの迅速なサポートと提供だけでなく、DevOpsチームとしての団結にも役立ちます。