CI / CDパイプライン:やさしい紹介

2019/05/23 09:00

高速でバグの無いコードを伝送するエンジニアリングチームが必要ですか?長期にわたって持続的にそれを実行するためには高速で信頼性の高いCI / CDパイプラインが必須です。

CI / CDパイプラインとは?

CI / CDパイプラインは、ソフトウェア配信プロセスにおけるステップの自動化を支援します。例えば、コード構築の開始、自動テストの実行、ステージングまたは運用環境への展開などです。自動化されたパイプラインは手作業によるエラーを取り除き、標準化開発フィードバックループの提供、および迅速な生成反復を可能にします。

CIとCDの意味とは?

継続的統合 (Continuous Integration)の略であるCIは、全てのソフトウェア開発者が1日に複数回セントラル・レポジトリでコード変更を統合するソフトウェア開発手法です。 CDは継続的配信 (Continuous Delivery) を表し、ソフトウェアリリースプロセス全体を自動化する方法を継続的統合 (Continuous Integration) に追加で加えます。

CIでは、コード変更の度に指定されたプロジェクトのビルドとテストの自動シーケンスがトリガーとなり、その変更を行う開発者にフィードバックされます。 全体のCIフィードバックループは10分以内に実行されます。

継続的配信 (CD) には、インフラストラクチャ・プロビジョニングと展開が含まれ、これらは手動で実行され複数のステージで構成されることもあります。これら全てのプロセスが完全に自動化され、それぞれの実行が完全にログに記録され、チーム全体に可視化されていることが重要です。

詳細はこちら:継続的統合、継続的配信、および継続的開発の違い。

CI / CDパイプラインの要素

CI / CDパイプラインはオーバーヘッドのように感じられるかもしれませんが、実際はそうではありません。ソフトウェア製品の新バージョンを配信するために必要とされる実行ステップにおいて、本質的に実行可能な仕様です。 自動化パイプラインが無くとも、エンジニアはこうした手順を手動で実行する必要がある為、生産性が大幅に低下します。

ほとんどのソフトウェアは数回の典型的な段階を経てリリースされます。

CI / CDパイプラインのステップ

各段階で障害が発生した場合、通常その原因を開発責任者に知らせる電子メール、Slackなどに送信されます。 さもなければ、通常は生成への展開が成功する度にチーム全体に通知が送信されるように設定されています。

ソースステージ

ほとんどの場合、パイプラインはソースコードリポジトリがトリガーとなって発動します。コードの変更がトリガーとなりCI / CDツールへの通知が送信され、CI / CDツールは対応するパイプラインを稼働します。他の一般的なトリガーには、自動的にスケジュール化された、あるいはユーザーが起動したワークフロー、および他のパイプラインによる結果が含まれます。

ビルドステージ

ソースコードとその依存関係を組み合わせて、エンドユーザーに出荷出来るような可能性を秘めた実行可能な製品例を製作します。 Java、C / C ++、Goなどの言語で書かれたプログラムはコンパイルする必要がありますが、Ruby、Python、およびJavaScriptなどのプログラムはこのステップなしで動作します。

言語に関係なく、クラウドネイティブソフトウェアは通常Dockerと共同で展開されます。その場合、CI / CDパイプラインのこの段階でDockerコンテナが構築されます。

ビルドステージをパスしなかった失敗については、プロジェクトの構成における根本的な問題を示しており、最善策は直ぐにそれに対処することです。

テストステージ

この段階では、コードの正確性と製品の動作を検証するために自動テストを実行します。 テストステージは、容易に再現し得るバグがエンドユーザーに届いてしまう事を防ぐための安全策として機能します。

テストの記録責任は開発者にあり、テストまたは動作駆動開発の過程で新しいコードを書くときに最適に活用されます。

プロジェクトの規模と複雑さに応じて、この段階は数秒から数時間続くことがあります。 多くの大規模プロジェクトの場合、複数回に渡ってテストは実行されます。迅速に健全性をチェックするスモークテストから始まり、ユーザー視点からシステム全体をテストするエ徹底的な統合テストまで行います。大規模なテストスイートは通常、実行時間を短縮するために併行して実行されます。

テスト段階での失敗により開発者がコードを書くときに予見できなかったコードの問題が露呈します。 この段階で迅速に開発者へ生成をフィードバックすることが重要です。一方で、問題の範囲は開発者の頭の中ではまだ未然に防げる段階にあり、彼らはフローを維持することが出来ます。

デプロイステージ

事前定義した全テストに合格した実行可能なコード例が作成されたら、展開準備が整います。通常、製品チームによって内部的に使用される「β」または「ステージング」環境、およびエンドユーザー向けの「生成」環境などを例とした、複数の展開環境があります。

テストとリアルタイム監視を手引きとしたアジャイル開発モデルを採用したチームは、通常、手作業で処理中のステージング環境へ展開し、追加の手動テストとレビューを行い、生成へのマスターブランチからの承認済み変更を展開します。

CI / CDパイプラインの例

パイプラインを始める事は非常に簡単です。コードのコンパイル、コードスタイルのチェック、および2つの並列ジョブで自動化テストを実行するGoプロジェクトのパイプライン例を御覧ください。

Goプロジェクト用の簡単なCIパイプライン

Kubernetesクラスタへのマイクロサービスの構築、テスト、およびビルドのより複雑な例を紹介します。

DockerとKubernetesによるCI / CDパイプライン

セマフォドキュメンテーションにCI / CDパイプラインの他の例が載っています。

パイプラインのその他の利点

CI / CDパイプラインにより、以前行って来た事よりも、より良い効果が現れもう少し効率的になります。

  • 開発者はコードの作成と作成中のシステムの動作監視に集中することが出来ます。
  • 品質保証部門および製品の利害関係者は、システムの最新バージョンあるいはその他のいかなるバージョンにも容易にアクセス出来ます。
  • 製品アップデートへのストレスはありません。
  • 全コード変更、テスト、および展開のログはいつでも閲覧可能です。
  • 問題が発生した場合、日常的なプッシュボタン操作で以前のバージョンにロールバック出来ます。
  • 迅速なフィードバックループにより、学習と責任という組織文化構築を支援します。

詳細はこちら:学習文化構築を支援する継続的配信学習の7つの方法

良いパイプラインとするには?

優れたCI / CDパイプラインを導入すれば、高速で信頼性の高い正確なパイプラインが築けます。

速度

スピードはいろいろな形で現れます。

  • いかに早く自身の仕事の正確性についてフィードバックされますか?一杯のコーヒーを飲むより時間が掛かるのであれば、コードをCIに押し込むのは、問題解決の途中で開発者に会議への参加を求めるにも等しいことになります。開発者にとってはコンテキスト切換えが不可避となり、効果的には機能しないでしょう。
  • 単純なコードコミットの作成、テスト、および展開にどれくらい時間がかかりますか? 例えば、CIの展開に合計1時間を要すということは、エンジニアリングチーム全体での展開は丸1日で最大7つまでに制限されるという厳しい事実を意味します。これにより開発者は、今日のビジネスで必要とされている急激な変化の代わりに、頻度の少ないよりリスクの高い展開を選択することとなります。
  • 弊社のCI / CDパイプラインは、リアルタイムで開発要求を満たせるように拡張出来るでしょうか? 従来のCI / CDパイプラインは容量が限られており、一度に実行できるパイプラインの数はある程度限られていました。 その結果、開発者は1日の忙しい時間帯にCI / CDが使用可能になるのを待つ間、リソースをほとんど遊ばせておく事となります。 最近リリースされたセマフォ2.0の最大変更点の1つは、自動スケーリングと、開発者の生産性をサポートする「サーバーレス」従量課金制モデルです。
  • 新パイプライン設定はどれくらい速やかに出来るのでしょうか? CI / CDインフラストラクチャの拡張や既存の構成を再利用する事が難しいと、摩擦が生じ開発が進まなくなります。今日のクラウドインフラストラクチャは、新たなCI / CDパイプラインの頻繁な初期化を要求するマイクロサービスで構成されたソフトウェアを書き込む事により最適に利用されています。この問題は、プログラム可能で既存の開発ワークフローに適合するCI / CDツールを用意し、レビュー、バージョン化、および復元が可能なコードとしての全CI / CD構成を格納することによって解決されます。

詳細はこちら:何故クラウドネイティブの成功は高速CI / CDに依存するのか。

信頼性

信頼に足りるパイプラインは、常に入力に比例した出力を生成し、実行の際にぶれることはありません。 断続的に発生する障害により、開発者間では激しいフラストレーションが巻き起こります。

成長中のチームにオンデマンドでクリーンな同一且つ独立したリソースを提供するCI / CDインフラストラクチャの運用と拡張は複雑な仕事です。 1つのプロジェクト、あるいは数人の開発者に対しうまく行っているように見えるものは、通常、チームとプロジェクト数の増加、あるいはテクノロジースタックの変更に伴い機能しなくなります。新ユーザーから情報を聞きつけた場合は、信頼性の低いCI / CDのセマフォへの移行が主な理由の1つです。

正確さ

ある程度の自動化は受け入れられるべき変化でしょう。 しかし、CI / CDパイプラインが正確に実行され、ソフトウェア配信プロセス全体が可視化出来るまでは作業は完遂しません。この為には、シンプル且つ必要に応じて複雑なワークフローの双方を形成出来るCI / CDツールの使用が求められ、繰り返すタスクでの手動エラーは有り得ません。

例えば、CIフェーズを完全に自動化する事は珍しくはありませんが、チームのたった1人が頻繁に手動操作により展開することは止めましょう。CI / CDツールが、機密複数のステージによるプロモーションなどを使用して、必要なワークフローの展開を形成すれば、こうした障害は解消出来ます。

すべき事

マスターが壊れたら、今している事をやめて修正します。 パイプラインで「ウィンドウが壊れていない」という方針を維持するのです。

最初に速やかに基本的なテストを実行してください。 大規模なテストスイートを使用している場合は、実行にかかる時間を短縮するために並列化するのが通常のやり方です。但し、重要なユニットやコードの品質テストに失敗した場合、時間を要するUIテスト全てを実行しても意味を成しません。代わりに、セキュリティスキャンや単体テストなどの高速で基本的なテストを最初に実行し、合格したパイプラインにのみ統合テストまたはAPIテストを受けさせ、最後にUIテストを実行するという複数のステージでパイプラインを設定する方が最善です。

常に同じ環境で実行してください。次に来るパイプラインが実行される環境でパイプラインがその環境を変更してしまう場合、CI / CDパイプラインは信頼出来ない事になります。各ワークフローが全く同じで、クリーン且つ隔離された環境から開始されるのが最善です。

品質チェックを組み入れます。 例えば、コードスタイルからセキュリティスキャンまで、あらゆる主要プログラミング言語に対し静的コード分析を提供するオープンソースツールがあります。 CI / CDパイプライン内でこうしたツールを実行すれば思い悩まず創造的に問題が解決出来ます。

プルリクエストを含めます。 CI / CDパイプラインが1つ以上のいくつかのブランチに限定される理由などありません。 あらゆるブランチおよび対応するプルリクエストに対して行われる標準的な一連のテストにより寄稿者は、ピアレビューを行う前、あるいはマスターブランチと統合するポイント以前で悪化する前に問題を特定できます。 このプラクティスの結果、いかなるプルリクエストもマージされても大事には至りません。

各プルリクエストをピアレビューします。 新コードをレビューする必要があり、完全に置き換えられるCI / CDパイプラインはありません。 変更が実際はあまりにも些細であるが為、ピアレビューに時間を浪費する場合も多々あります。しかし、全てのプルリクエストは目視する必要があるという規範を設定し、例外はその意味がある場合にのみ適用するのが最善策です。 ピアコードレビューは、協力的に問題を解決するという強力でエゴの無いエンジニアリング文化を築く上で重要な要素です。

CI / CDパイプラインの実施準備は整いましたか?

セマフォは、自動スケーリングおよび従量課金制価格モデルにより、Dockerおよび主要なプログラミング言語を根っからサポートする最速のクラウドベースのCI / CDサービスです。新しくパイプラインを生成するには、簡単な手順がいくつか必要です。

セマファの使い方の実地デモビデオの1つを見てもよいでしょう。

Happy building!

この記事は、著者の許可を得て翻訳しています。なお、原文はこちらです。

新着ピック  






















新着ニュース

LINE「OpenChat」、トークルーム検索機能の再開を延期 「検索精度を上げるため」

バーチャルタレントがスナックのママに--“場所を選ばない接客”の働き方

リザーブドインスタンス(RI)を間違わずに購入したい! それなら AWS CLI を活用してみよう。 -オペ部だより- | DevelopersIO

ローソン、「深夜に店員ゼロ」を実験へ QRコードで入店、セルフレジで決済 遠隔監視で万引き防止

銘菓「ニコンようかん」、ネット販売終了 「裏の主力製品がなくなる」と惜しむ声

WindowsでAWS CDK(C#)の開発環境を整えてみた | DevelopersIO

TC Tokyo超早割チケットは8月末まで!トヨタの自動運転開発子会社TRI-ADのCEOが登壇決定 | TechCrunch Japan

たこ焼きロボからマイクロモビリティまで竹芝埠頭にロボ集結 | TechCrunch Japan

家事代行のベアーズ、マンションにスタッフ常駐の新サービス「MAUCHI」開始

対象店舗でビットコイン決済するとTポイントを付与--bitFlyerとTポイントが業務提携

野村不動産アーバンネット、不動産売買支援システム「Kimar」を導入

Application Load BalancerのリスナールールによるIP制限 | DevelopersIO

Application Load Balancerのリ...

DevelopersIO / 3時間前


最短2日で物件売却のすむたすが直販を開始--「すむたす直販」が担う中古流通比率の引き上げ

ローソン、深夜時間帯を“無人化”する実証実験--横浜で半年ほど実施

Amazon VPC設計時に気をつけたい基本の5のこと | DevelopersIO

ソニー、学校向けプログラミング学習キット「KOOVベーシックキット」を9月に発売

「Zaif」元運営のテックビューロ、仮想通貨交換業を廃業へ

なぜβ版でスタート? 独自プランは? IIJに聞く「eSIM」戦略

Github ActionsのワークフローへCircleCIのワークフロー流用を試してみた | DevelopersIO

ブランドリセール「RECLO」のアクティブソナー、中国企業などから約36億円を調達

もっと見る
ログイン
会員登録
Register
記事をPICKする

会員登録すると、もっと便利に利用できます。