Jenkinsは、企業で最も広く利用されているオープンソースの継続的インテグレーションサーバーです。今日は、Pipeline as Codeについて一緒に考えてみましょう。

これを保存しておいてください。後で必ず必要になります。

まず、Pipelineが導入される前は何が起こっていたのかを理解しましょう。私たちは課題でフリースタイルプロジェクトを多く使用していました。このタイプの課題の大きな特徴は、すべての設定がWebページ上で行われていたことです。これが問題を引き起こしました。

これらのパラメータを大量に変更する場合、コンソールで各ジョブの構成を繰り返し変更する必要があります。

Jenkins 2.0では、パイプラインというコア機能が導入されました。パイプラインの実行プロセス全体をコードで記述できます。このコードはバージョン管理システムやプロジェクト内に保存でき、このようにコードを書くだけで済みます。最終的に、パイプラインはどのような問題を解決し、どのようなメリットをもたらすのでしょうか？

複数のプロジェクトがある場合でも、統一されたパイプラインコードを使用して管理できるという利点があります。つまり、後からパイプラインステップを追加しても、そのコードに追加されます。

最後に、パイプラインコードのフォーマットを見てみましょう。これは後ほど記述するパイプラインです。また、こちらも記述する必要があるコードです。

本日共有したコア機能を要約してみましょう。

• フリースタイル プロジェクトの問題点の 1 つは、すべての構成がページ上にあるため、変更するのが面倒なことです。
• パイプライン型プロジェクトでは、パイプラインをコードで記述するため、大規模な変更が必要な場合でも、ソースコードを変更するだけで済みます。これは運用・保守担当者にとって非常に便利です。

最後に、ちょっとした疑問を提起したいと思います。Jenkinsfileが複数あり、それぞれに数千行ものコードが含まれている場合、管理が非常に面倒になるのではないでしょうか。この問題を解決するには、どのようなベストプラクティスを適用できるでしょうか？