【開発モダナイゼーション】特別編2 IBM i開発におけるDevOpsとGitとは?

IBM i 7.5と共に発表されたMerlinは、IBM iの開発環境にDevOpsという現代的な開発手法を提供する製品として注目されます。このMerlinの発表のちょうど1年前、ARCAD社でDevOpsのマネージャーを務めているアンドリュー・クラーク氏が、IBM iの開発環境を念頭にDevOpsとGitについて語っています。Merlinの真価ならびにIBM iの開発環境の将来像を理解する上で大変参考になるこの対談を抄訳しました。是非ご一読ください。(編集部)

2021/5/3　チャーリー・グアリーノ

チャーリー・グアリーノ(以下、チャーリーと略します)： みなさん、こんにちは。TechTalkの別エディションにようこそ。今日は、ARCAD Software社のDevOpsマネージャーのアンドリュー・クラーク氏をお招きしています。彼はIBM iで30年の開発経験があり、Db2 for iおよびクロスプラットフォームのSQL全般の専門家です。現在、彼はコーディングと日常的なDevOpsの使用の両方の責任者です。アンドリュー、ご出演ありがとうございます。

アンドリュー・クラーク（以下、アンドリューと略します）： チャーリー、ご紹介ありがとうございます。

チャーリー： あなたの略歴を読んでいて目に飛び込んできたのはDevOpsです。これは何年も前から聞いてきた言葉ですが、ここ数年ですっかり定着し、今や業界の多くの開発者には本当に当たり前になったと思います。まだ人によっては少し聞きなれない言葉ではありますが、DevOpsが実際に何であるか、簡単な定義またはもう少し詳しい説明をしてもらえますか。

アンドリュー： DevOpsは「開発（Development）と運用（Operations）」の略語で、この2つの組み合わせです。つまり、DevOpsは開発に携わる人、および運用や品質保証すなわちテスト、あるいはデプロイに携わる人のためのものです。実際DevOpsには、両者の考え方が織り込まれており、複雑なプロジェクトをデプロイするプロセスを簡素化するという考え方です。コードがエンドユーザーにデプロイされる前、特にコードが本番環境にデプロイされる前に、殊にセキュリティ、テスト、検証を社内で可能な限り沢山行うことでこれを実現します。社外に顧客がいる場合、本番環境に供したときにコードにバグやエラーが紛れ込んでいると、特に修正コストは天文学的なものになります。たとえ自社の特定の部門内であっても、エラーを含む変更されたコードを実際に公開すると、会社にとって壊滅的な打撃になる可能性があります。DevOpsの全体的な考え方は、皆さんが見覚えのある大きな開発曲線で表されるシフトレフト効果（訳注1）と呼ばれ、基本的に全てのテストおよび回帰テストをエンドユーザーがコードを見る前に、開発／運用の開発サイクル側で実行し完了します。これにより、可能な限りの最高のコード品質が保証されます。設定作業には少し手間がかかりますが、使い始めれば魔法のようなプロセスになります。私達はそれをシステムに統合しており、変更を加えた後、自動的にビルド関連の全てが確認されデプロイされるのは、本当に魔法のようです。全てが機能するようにすると、そこで起ることはとても信じられないものです。

チャーリー： 私達は業界にいて、二人とも30年以上これをやっています。私が最初に働き始めたとき、伝統的なアプローチでは、一連のプログラムを選び、おそらく1週間以上、場合によっては1か月待ってから、一連の物を全て一度にデプロイしました。あなたが説明したように、それは現代のパラダイムではありません。それについて話しましょう。なぜなら、伝統的アプローチはこの膨大な一連の変更をデプロイするのに最後まで待つ、本当に古いアプローチだからです。

アンドリュー： その通りです。あれはウォーターフォール方式のようなものです。あれはリリースサイクルのようなものであり、ある会社では四半期毎または年毎のリリースについて話しているか、あなたの言うように週毎のリリースです。DevOpsにおける全体的な考え方は、テストの準備が完了した使用可能な各ユニットは、プッシュして変更し、準備が完了したらすぐに環境に統合できるというものです。ですから、数百または数千のオブジェクトが存在するリリースを作るのではなく、オブジェクトが6つしかないリリースがあるかもしれません。ファイルの変更があり、それに関連する全てのプログラムがあるかも知れません。あるいは、新しいパラメータを持つプログラムとそれを呼び出し、使用する全てのプログラムがあるかも知れません。つまり、DevOpsサイクルで変更単位が発生する度に、それをプッシュして利用可能にすることができます。それは、エンドユーザーそしてお客様に、可能な最大限のセキュリティと共に最終結果を届けるプロセス全体を本当に迅速にします。

チャーリー： これは明らかに実際のCI/CD定義、つまり継続的インテグレーションと継続的デプロイ（訳注2）を詳しく述べたものですね。私達は、常に漸進的な変更を公開しています。

アンドリュー： そうですね、本当にその通りです。DevOpsの核心は、ユーザーにできるだけ早く漸進的な変更を届けることです。

チャーリー： そして、そのプロセス全体により、全体的なコード品質が改善されることが時の経過と共に示されてきました。

アンドリュー： ええ。GartnerのDevOpsの調査報告書でそれは証明されており、費用対効果も高いですよね。それは実際に長い目で見れば、企業のお金を、時には信じられない程のお金を節約します。私達はROIの計算を行っており、50人規模のユーザー組織および50人規模の開発者組織では、既存のテストケースが過去に処理された方法およびDevOpsができる事に基づいてDevOpsを直ちに正しく実装することで、年間100万ドルを節約できます。本当にコスト削減できると証明されています。DORAはその研究をしている組織で、毎年研究をしており、あなたはその結果にアクセスできます。非常に膨大なお金が節約できます。

アンドリュー： ええ、もちろんです。DevOpsの全体的な考え方は、開発サイクル内で多くのテストが自動化できるので、テストケースを設定していればそのテストを実行して非常に素早く統合できるというものです。大規模な組織のようにこれらの巨大なデプロイについて心配する必要はありませんが、DevOpsの多くの機能、特にGitのような機能が活用できます。これは必須条件ではありませんが、それは間違いなくあなたの生活をずっと楽にしますし、会社の規模に関係なく自動テストは重要です。バグを書くということは、会社の規模とは無関係に、やはりバグを書くということです。そしてあなたは、エンドユーザーがそれを見る前に、確実にそれに対処したいと考えています。それがあなたの株を上げます。開発者が1人か2人の組織にあなたが居て、何かがうまく行かないときはあなたが標的になります。いくつかのDevOps環境を整えたならば、突然それらのことを心配する必要がないことが分かります。それはあなたの人生をより良くします。

チャーリー： 現在、業界での明らかな魔法の言葉の1つはGitだとあなたは言いました。Gitはあらゆる所で使用されているので、今日では学校を卒業した人は誰でもGitを知っています。でも、もう一度話をIBM i使用企業に戻します。私達のコミュニティへのより大々的なGitの進出は今始まったばかりです。Gitについて話しましょう。まずGitとは何かについて、あなたの考えをお聞きしたいです。しかし、もっと重要なのは、開発者としてGitを使用することが重要な理由と、Gitソリューションを実装することでどのようにご利益が得られるかということです。

アンドリュー： オープンソースの世界におけるGitの大きな利点は、分散バージョン管理ができ、各開発者は基本的に自分のローカルPCにオブジェクトの自分専用のコピーを持てることです。IBM iの世界では、実際にコンパイルを行うのにIBM iが必要なので、分散モデル全体が一種の異質な概念、あるいはほとんどのGit開発者が使用しているものと異なる概念なので、それは一般的なGitとは違っていますが、非常に簡単に言うとGitはソース管理です。Gitを使ってバージョン管理が行え、Gitを使ってデプロイが行えますが、それはGitの本質ではありません。それは単にソースを管理しているに過ぎません。Gitの最大の利点は、基本的に並行開発に対応していることです。どの会社でも最大の問題の1つは、変更を行ったときにお互いの変更がぶつかることです。あなたはそれについて知りません。私達が単一ソースメンバーをコピーする話しをしているときに、誰かが変更を加え、他の誰かがやっていることを誤って元の状態に戻す可能性があります。従来のIBM iの世界では、ライブラリー全てをコピーし、完了したら本番環境にそれらのソースをコピーして戻すでしょう。さて、あなたがそれをしている間に誰かが変更を加えたらどうなるでしょう？つまり、それは時として壊滅的である可能性があります。ですから、Gitの最大の力は、実は同時変更という課題を解決する能力であり、衝突が起きないようにします。これはGitの大きな威力であり、誤って他の誰かの作業を上書きすることはできません。また、自動的にマージすることもできます。私は毎日Gitを使用しており、90〜95％の時間は自動的にマージが行われます。これは本当に良くできていて素晴らしいです。１つのソースに対するいくつかの変更版があったとして、それらはマージされそれで作業完了です。一般的な開発者にとって、編集/コンパイル/デバッグのサイクル全体は、Gitを使用したときでも全く同じです。しかし、これまでにない同時開発に対する保護全てがあります。作業している開発環境に関係なく素晴らしいツールです。

チャーリー： そしてもちろん、変更箇所を比較するためのGit diffを忘れてはいけません。

アンドリュー： ええ。一体となった比較とマージは本当に魔法の様です。間違いなくCMPPFMコマンドをはるかに超えています。

チャーリー： でも、それは未だに多くの会社が使用しているものです。Gitについてさらに話を進めましょう。バージョン管理について話しましたが、今はソースメンバーにいくつかの変更を加えた環境にあり、それらをプロモートする準備ができています。現在、プロモートはいくつかの形式を取ることができます。直接本番環境に移行することもできますが、この間にテストフェーズがある筈です。それについて話しましょう。そして典型的なデプロイサイクルについて話しましょう。

アンドリュー： 実は、DevOpsの想定では、全てのDevOpsサイクルを実行しようとするなら、その全サイクルには開発者がいつも使い慣れているのと同じ編集/コンパイル/デバッグステップが含まれていると考えています。それから自動テストもあります。何が起こるかというと、バッチで自動的に実行できるテストケースが生成されます。それらは何も考えずに実行できます。しかし、これらのことを行う「最善」の方法は、プログラムをソースプログラムやモジュールと同様に設定することです。それらはテストケースから呼び出せ、結果を検証できます。開発者はローカルで独自のスモークテスト（訳注3）を実行するでしょうが、次に彼は自分が変更しているオブジェクトに関連付けられた全テストケースも実行するかも知れません。今、彼は完全な回帰テストを行うつもりはありません。彼は単にそれらの小さなサブセット、つまり彼が作業を行っているコードの単体テストを実行するつもりです。次に、DevOpsサイクルで、彼はその変更をある種の自動ビルドシステムにプッシュし、それによって完全な回帰テストが実行されます。変更がある度に、品質保証環境、本番環境、またはどんな構成であっても、次のステップへのデプロイのような何かが実際に行われる前に、変更されたオブジェクトに対して完全な回帰テストが実行されます。 もう1つ、回帰テストだけでなく、SonarLintのようなコード品質についても話しをします。あなたはコードがある種の品質基準を満たしていることを確かめるルールを持っているかも知れません。そしてそれについて、私達は丸々1時間話すことができます。あるいはSonarQubeのようなものについて話すことができます。SonarQubeは、バグやセキュリティ脆弱性に繋がる可能性をもつセキュリティホールがあるコード、またはバグにつながる可能性のあるお粗末なプログラミングスタイルのコードを検出します。つまり、コードは次のサイクルに進んで統合される直前に、これら全ての品質チェックに合格する必要があります。全ては自動的に行われ、それらのいずれかが失敗した場合、基本的にコードは失敗として返され、次のステップに進む前に修正を加える必要があります。

チャーリー： 今あなたが説明したことは全て非常に強力です。これら全てのテストと全ての安全性チェックを行ったとしても、必ずコードはエラーのある本番環境に移されます。そのような場合Gitはどのように役立ちますか？

アンドリュー： その時点で、実際にはDevOpsサイクルでそれらのエラーを阻止しようとしますが、エラーが本番環境に出てしまった場合、サイクルは基本的に同じです。良いホットフィックスを使用してGitで何かを行うことができます。私達はブランチを作ることができます。これは、素早く変更を行う方法です。Gitを使用していたとしても、方法論は現在のやり方にとても良く似ています。それをホットフィックス用のような場所にコピーします。修正を加え、それからその間のステップの幾つかを飛ばして緊急プロモーションを行います。ですから、こうしたケースにもGitを使用する方法はあり、それは現在やっているかも知れない事にとても良く似ています。あなたが加える修正を待たず、ホットフィックスを再デプロイしてそれらの手順を実行します。ホットフィックスを使用したとしても、修正が本番環境にプッシュされる前に、全てが適正であることを確かめるために、あなたはテストケース全てを再度実行するでしょう。

チャーリー： 私が最初にGitを見たとき、最初に出会ったのはグラフィカルツールではなく、Gitを使用したコマンド行でした。Gitは最初そのようにコマンド行と一緒に設計あるいは作成されたと思います。コマンドを使うことを主張する何人かの開発者のことを聞いていますよね。これは「コマンド行Git対グラフィカルツール」と呼ばれるものですが、何故あなたは人々を「コマンド行Git対グラフィカルツール」へと先導するのですか？

アンドリュー： Gitはコマンド行駆動です。Gitはリーナス・トーバルス氏によって作成されたものであり、Cプログラムです。それはコマンド行であり、全てのシェルは基本的にGitコマンド行を使って動作し、Gitコマンド行が実行する事の上にあるに過ぎません。コマンド行を使って何でも実行できます。これは、ちょうど5250と同じように、コマンド行でGitを操作するための最も強力な方法です。WRKSPLFやDSPxxxあるいはWRKMBRPDMコマンドで必ずしもできるとは限らない多くの事がコマンド行で実行できます。自分がしている事を本当に知っているなら、いかなる種類のインターフェースも持たないコマンド行で、あなたが実行できる驚くべきコマンドがあります。それらに対するシェルも画面もメニューも、あるいは同じだけの力を発揮させる物もありません。Git用のEclipseのプラグインであるEGitのようなシェルは、それをずっと容易にします。Gitはもっと速く学習でき、正直私は毎日使用しています。実際私は99％の時間をEGit内で全てを実行していますが、EGitインターフェースでは実行するのが難しい幾つかのタグや事柄があったり、自分がGitコマンド行でしている事を本当に理解していたりする場合があり、そのようなケースではグラフィカルインターフェースがどのように機能しているかを理解できるのに加え、それらのシェルの内部で行うのが実際には難しい幾つかの付加的な作業が行えます。

チャーリー： 私がGitを学んだ方法はコマンド行でした。そして、学習の過程でコマンドの幾つかを知っていると、グラフィカルツールにもっと早く適応するのに役立つことに気付きました。そして、あなたが言うように、何だかんだ言っても陰でコマンドが実行されています。

アンドリュー： そうです。どのみちコマンドが実行されており、概念が何であるかを理解していることが重要です。Gitコマンド行はとても難しそうに見えるかもしれませんが、基本を知っておくのは良いことです。それを使いたい場合、私はEclipse内で開発を行っているので、グラフィカルシェルを使う方が速いことに気付きましたが、必ずコマンド行に切り替えています。あなたは快適である必要があります。コマンド行を使用する必要がある場合があり、Gitの全機能を本当に活用するには、舞台裏で何が起こっているのかを理解することが重要です。それについて疑問の余地はありません。

チャーリー： 私達はこの会話をDevOpsという用語で始めました。これは人々が日常的に使用する用語であり、それはコミュニティの仲間言葉ですが、もっと新しい用語はDevSecOpsです。 その起源は何ですか？なぜここでSecつまりセキュリティをDevOpsに追加したのですか？

アンドリュー： これは自動デプロイのセキュリティコンポーネントで、開発者が変更をリポジトリにプッシュした後、自動テストケースが実行されます。ですから、これは全て従来のDevOpsですが、自動セキュリティチェックもあります。これらは先ほど述べたSonarQube、SonarLintおよびSonatype のようなものです。これらは、SonarQubeのようにコード内で本質的に危険なこと‐例えばnullポインターエラーが発生する可能性があるようなこと等‐を行っていないことを確認します。それからSonatypeは実際にサードパーティ製品のセキュリティ脆弱性を検証します。オープンソースの世界で重要なのは、これらのサードパーティ・パッケージを全部使用することです。開発スタックに含まれているものは数百とは言わないまでも数十あります。問題は、これらのサードパーティツールの1つにセキュリティの脆弱性があり、自社の製品をそれらのツールと一緒に出荷した場合、セキュリティの脆弱性に晒されます。 例えば、ターゲットの全データ漏洩のような事は、脆弱性のあるサードパーティのツールを使用していて、それを修正しなかったために起きます。これは既知の修正可能なコードであり、この脆弱性のあるコードを使用したプロダクションコードは存在し続けますが、これらはDevSecOpsで自動的に捉えられるものです。それをDevOpsに含めてグループ化します。昔はそうではありませんでしたが、それは自動化されたサイクル全体の一部になっています。開発者が変更をプッシュした直後に、自動化されたテストとセキュリティチェックが行われ、次いでデプロイが行われます。つまり、それはステップ間で行われ、重要なプロセスなのです。

チャーリー： あなたはここで多くの異なるツールについて話しました。SonatypeとSonarQubeについて話しましたが、私が小さな組織にいる場合、これら全ての異なる様々なものを一度に実装する必要がありますか？あるいは、本当にこの道を進みたい場合（皆そうするべきだと思いますが）、どのように始めたらいいのでしょう？これら全てのエキスパートツールを入手する必要がありますか？あるいは、あなたのお奨めは何ですか？

アンドリュー： 小規模な組織の場合、手始めにどんなツールでもいいですから使い慣れている物の中でGitを使い始めることです。私の考える最も簡単な方法はRDiを使うことです。少なくともRPGのエディターとしてRDiを開発に使用しているといいのですが、RDiはiProjectsと呼ばれるパースペクティブとの統合が非常に簡単で、QSYSソースファイル中のソース文字列ファイルを引き続き操作できます。ですから、実際のところシステムの構成方法について何も変更する必要がありません。これにより、まず始めてみてGitに取り組み、DevOpsサイクルを開始し、Gitでできる事を準備し、それらをマージする並行開発が実際に始められます。そしてひとたびそれが統合されたら、他のツールの使用を考え始めることができます。あなたはGitを使用していますから、自動ビルドシステムの一種であるJenkinsのような他のツールを接続し、コードチェックを可能にするSonarQubeのような他のツールを容易にデプロイできます。正直なところIBM iの世界では、SonarQubeとSonatypeはオープンソースの世界ほど適用性は高くありませんが、Jenkinsと直接統合して同じことをIBM iで実行できるARCAD社の製品などが確かにあります。

チャーリー： そうですが、ある程度の計画を立てる必要があります。いきなり飛び込まないでください。事前の計画が必要です。このプロセスを理解し、その実装を通しでガイドできる人が必要です。

アンドリュー： ええ、全くその通りです。社内のどのような知見も常に使うべき最高の知見です。VSCodeのようなツールを使い慣れている人がいる場合、あるいはGitHubの代わりにGitLabまたはBitbucketのようなツール（これらのGitベースのリポジトリはどれも、ほとんどがクラウドベースですが）を使い慣れている人がいる場合、またはあなたがそれに触れている場合は、この情報を本当に理解している人を起点に開始するのが常に最善のやり方です。その知識が全くない場合、一番簡単な方法は、まずCOMMONのようなものから始め、ポッドキャストを使用し、RDiを開始してGitコマンド行にある程度触れ、そこでインテグレーションがどのように機能するかを確認することです。それによって、あなたの旅が本当に始まります。それは世の中にある物の可能性に対して本当にあなたの目を開くと思います。

チャーリー： そして、私の考えではそれが本当に重要であり、あなたはそれに同意すると思います。ソースコードを適切に管理することはとても重要です。それはどんな企業にとっても本当に大変戦略的な資産です。どのような場合であれ、 何百万ドルまたは何十億ドルもの実際のお金が月次、年次ベースでアプリケーションを通過します。ですから、会社の決定的に重要な戦略的資産として管理することがとても重要です。

アンドリュー： 全くその通りです。それはかけがえのないものです。つまり、ソフトウェア会社の場合それは会社の全資産であり、ソフトウェア会社でない場合でもそれはやはり多くの時間です。業界において、あなたの会社の他社に対する優位性はソースコードです。本来あるべき品質よりも低い品質のソースコードやオブジェクトを作成したりするのは、ビジネスにとって不利です。低品質のコードはお金を食います。そして、DevOpsの背後にあるあらゆる原動力は投資収益率です。DevOpsサイクルを正しく実装するだけで、数百万ドルを節約できることを示す計算結果があると言っておきましょう。

チャーリー： あなたが前に言った事ですが、本当に痛切に感じたので繰り返したと思います。明らかに、問題を識別するのがプロセスの早い段階であればある程、皆が豊かになり、間違いなく少ないコストで済ませることができるでしょう。

アンドリュー： そうです。コストを考えると、基本的に開発者がバグを修正できれば1のコストで済みます。次のサイクルであるテストサイクルつまり品質保証サイクルに到達し、修正が必要な場合は、コストは4倍になります。次に、デプロイサイクルに到達してバグが発見された場合、10倍のコストがかかります。そして最後に本番稼働になると、640倍のコストになります。社内での修正にかかるコストが何であれ、640倍のコストは、現実の時間および費やした時間の喪失だけでなく、評判の失墜にも繋がります。正しくないものを出荷すると、人々はあなたが開発中のソフトウェアを信頼しないので、ビジネスに悪影響を及ぼします。そのため、莫大なコストがかかります。そのことはずっと研究されてきました。

チャーリー： 皆の自信と信頼を取り戻すのはとても難しいです。

アンドリュー： ええ、その通りです。

チャーリー： アンドリュー、考えさせられる事が沢山ありました。今日は、DevOpsサイクル全体およびDevSecOpsについて話してくれて本当にありがとうございました。これは魅力的なトピックです。これはもう１つの本当に重要なステップであり、会社を経営している場合は、これを調べる必要があります。これは、間違いなくアプリケーションライフとソフトウェア開発ライフサイクル（SDLC）で行う事の全体的な組み合わせの重要な構成要素ですね。

アンドリュー： その通りです。ここでは、非常に複雑な話題を非常に短時間で簡単に説明しましたが、これらのそれぞれについて何時間も話し続けることができます。Gitは時間であり、セキュリティは時間であり、自動化されたデプロイ等これら全ては開発プロセスの改善を可能にする継続的な学習サイクルと言えるでしょう。

チャーリー： お時間を頂き本当にありがとうございました。この対談でのあなたの経験談と事例から、多くの人が本当に恩恵を受けるだろうと思います。どうもありがとうございました。

---