DevOps普及の背景
最初に、IBM iユーザーにとってのDevOpsの定義から見ていこう。
今までのIBM iでの開発では、システム稼働環境を固定化し、アプリケーションの変更を最小化することで、システムの安定性を担保してきた。それが従来型のアプローチであり、基幹システム開発での常識でもあった。
強固に統合されたプログラミング言語やデータベースシステムを中心とした開発・実行環境で、アプリケーションを構築する。中央集権体制にも似た開発スタイルである。そこには、環境を固定化することで品質や効率を高める狙いがある。
そのためコード編集、コード管理、ビルド管理、デプロイ管理など、それぞれのツールの連携や自動化はあまり重要視されてこなかった。この考え方は大規模プロジェクトを中心に今も有効ではあるが、ビジネスのスピードがシステム開発を追い越していく今日のニーズにそぐわない面があるのは確かだ。
その一方、IT市場全般では、開発からリリースまでの時間を最短化し、ビジネスのスピードに追随しようとする動きが活発化している。当初は小規模かつ新規事業の領域で、ビジネスの立ち上げを重視するような場面において、さまざまな取り組みが行われてきた。試行錯誤を前提としたアジャイルや開発チームに着目したスクラムなど、多種多様な手法が試行されている。
そうした取り組みが進むなか、開発・運用など各ツールの連携性を高め、自動化を徹底する必要があるという認識が広がってきた。現在では目的・機能別にシステムを組み合わせて最適システムを構築するため、以前よりはるかに手間のかかる運用管理が求められているからだ。
人手に頼るような開発・運用は、もはや現実的ではない。中規模かつ既存業務の領域にも、こうした動きが広がっている。つまり基幹業務であっても、信頼性を確保しつつ、ビジネスのスピードに合わせて開発を進化させていく必要がある。
ここで、IBM i ユーザーの視点から今までの情報を整理してみよう。図表1は、IBM iでは見慣れた垂直統合のシステム構成である。長年にわたり各階層の境目を厳密に維持し成長させることで、システム全体の整合性を確保し、アプリケーション開発・運用に専念できるようにしている。
このようなアーキテクチャを堅持することで、IBM iは基幹業務の開発・運用維持が容易なプラットフォームとして評価されてきた。しかしIBM iであっても昨今のシステム化のトレンドに抗うことはできず、複雑化するシステムへの対応が迫られている。ソーシャル、クラウド、AI、IoTなどさまざまなシステムと連携し、今まで以上にビジネスに貢献することが求められている。IBM i上の基幹業務であっても、システムをタイムリーに更改できるような環境整備が急務である。すなわち、開発・運用に関わるツール間の連携や自動化が必要なのである。
IBM iで利用可能な
DevOpsツール
ここで言う連携や自動化は多種多様だが、まずはプログラム生成、プログラムデプロイの自動化から始めるのがよいだろう。次にテストの自動化や稼働環境の自動構成などへ、段階的に進めていく。IBM iでは開発ツールとしてSEU、PDM、SDAなどがあり、運用はコマンド、CLプログラムを使っていた。しかし昨今は、Rational Developer for i(以下、RDi)に代表されるオープン系の開発ツールが主流になりつつある。
運用などは依然としてコマンド、CLベースが大半であるが、複数システムの一部として運用する場合は、システム全体で統一した運用ルールに乗せるべく、いろいろなツールが提案されている。図表2に、各層で利用可能なIBM iの開発・運用ツールを示した。
開発インフラの層には、親しみ深いコード編集ツールであるSEUに加えて、RDiやOrionがある。コード変更管理ツールとしてはRational Team Concert(以下、RTC)、Gitなどが配置されている。これらのツールを利用して連携のメリットを理解するところから、IBM iユーザーのDevOpsへの道が広がっていく。
ツールについてはPart 2、Part 3で詳しく解説するが、その前に、IBM iではシステムやプロジェクトの規模によってDevOpsの取り組み方が異なることについて言及したい。図表3は2018年現在、IBM iで利用できる目的別のDevOpsツールである。
これはプログラマー視点でまとめたものであるが、最下段にあるプロジェクト規模を参考にしてほしい。プロジェクト規模が小さい場合は、今までどおりSEUで十分と思うかもしれないが、中・小規模のプロジェクトであっても、これからはOrionやGitなどのオープンソースをベースとしたDevOpsツールの活用が有効である点に目を向けよう。
これらのツールはオープンソースであるが、IBM iライセンスプログラムの一環として導入可能であり、有料フィーチャーでないことにも着目したい。
Part 2、Part 3を参考に、IBM i上で、DevOpsの入り口となる「コード編集~コード変更管理」の流れを試してみよう。DevOps的な考え方に少しずつ慣れていくことで、その都度必要なツールや連携を追加していくことが大切である。また大規模プロジェクトでツールの一貫性が求められるのであれば、IBM製品であるRTCなどを導入するのも一手である。今後登場するであろう新たなオープンソースベースのDevOps環境を取り入れてもよい。
ビジネスのスピードに対応するため、開発・運用サイクルの自動化を進め、効率よくシステムをリリースし、運用していくことがDevOpsの主たる目的である。そのための手段として各種ツールを利用するのであって、ツールに振り回されないように注意すべきである。とくにオープンソースをベースとしたツールは、流行りすたりが激しく、あっという間に新しいツールに取って代わられる。
IBM iでは、SEUなど何十年にもわたって提供されているツールが今も健在である。しかしDevOpsの考え方を取り入れていくならば、そうしたツールや環境を今までと同じように使い続けるのではなく、日々新たに進化させていくことが重要である。それらを積極的に取り入れ、対応していくことが、DevOpsの実現に必要なマインドであると言えるだろう。
・・・・・・・・
著者|箕手 幸広 氏
日本アイ・ビー・エム システムズ・エンジニアリング株式会社
アセット企画
コンサルティングITスペシャリスト
[i Magazine 2018 Autumn(2018年8月)掲載]
◎お知らせ
本特集の監修と執筆を務められた箕手幸広氏は9月にお亡くなりになりました。
謹んでご冥福をお祈りいたします。
・・・・・・・・
特集|IBM iのDevOpsアプローチ ◎目次
IBM iの基幹システム開発にも、これからはDevOpsアプローチが求められる
・・・・・・・・
・・・・・・・・
オープンソースのGitを利用して、ソースコードや変更履歴情報を共有する
・・・・・・・・
IBM iでJenkinsを使う、オープンソースベースの標準的なビルド管理を実現
[i Magazine 2018 Autumn(2018年8月)掲載]