Pocket

CircleCIで下記のように複数のStg環境デプロイがあった場合、jobを毎回指定していました。コード自体の可読性は上がりますが、やたらコードが長くなってしまったり、メンテナンスがしづらいというデメリットが生じてしまいます。今回はparametersを利用して複数のjobを関数化してコードをキレイにしてみました。

[CircleCI][ECS/Fargate]API v2を使って気楽にステージング環境をデプロイさせる


パイプライン値とパラメーター

https://circleci.com/docs/ja/pipeline-variables/

https://circleci.com/docs/ja/reusing-config/

  • パイプライン値: 設定ファイル全体で使用できるメタデータ。
  • パイプラインパラメーター: 型指定されたパイプライン変数。 設定ファイルの一番上にある parameters キーで宣言します。 parameters は、API からパイプラインの新規実行をトリガーする際にパイプラインに渡すことができます。

jobに対して定義した引数を渡すことが可能で、引数の型を指定してworkflowからjobに渡すことができます共通stepやパラメータを一元化できるのと、修正する箇所がパラメーターのみになるので修正コストが下がります。もちろんパラメーターに依存してしまうので、コードを把握する前提となります。


修正してみる

  • config.yml

3行目のparametersではenvという引数をstringで指定します。その後13行目から16行目で環境ごとの引数をparametersで渡し、workflowsで対象のjobs名と引数を指定するだけです。


まとめ

むちゃくちゃ便利か!しかもこんな書き方があるのを知らんかったぞ….バシバシparametersを使いこなしていこうと思います!

Pocket

カテゴリー: AWSCircleCI

adachin

1989年生まれのSRE。 ホスティングから大規模なアドテクなどのインフラエンジニアとして携わる。好きなツールはAnsible,Terraform,CircleCIで、ECS/Fargateでのインフラ構築を得意とする。副業では数社サーバー保守とベンチャー企業のインフラコンサルティングやMENTAで未経験者にインフラのコーチングを実施している。また、「脆弱性スキャナVuls」のOSS活動もしており、自称エバンジェリスト/技術広報/テクニカルサポート/コントリビュータでもある。現在はサービスの信頼性向上、DevOps、可用性、レイテンシ、パフォーマンス、モニタリング、緊急対応、インフラコード化、リファクタリング、セキュリティ強化、新技術の検証、Docker開発環境の提供、AWSでのインフラ構築、GCPでのGKE/Kubernetes保守などを担当している。

0件のコメント

コメントを残す

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください