知識のリンク集

技術系アウトプット

Circle CIとAWS SAMのデプロイ

今回はCircle CI設定ファイルを作成した際に触ったものについて調査内容をまとめる

なにはともあれ公式ドキュメント
Circle CI
https://circleci.com/docs/ja/2.0/configuration-reference/

Cicrle CIが動く条件

CircleCI と連携したリポジトリのブランチに .circleci/config.yml ファイルがあること
この時動かせるCircle CIのバージョンは2.1

orbs

(公式ドキュメント: https://circleci.com/docs/ja/2.0/orb-intro/)
ジョブ、コマンド、Executor のような設定要素をまとめた共有可能なパッケージ。

使用するためにはCicrcle CI version2.1であり、config.yml にて下記のように宣言する。

version: 2.1

orbs:
  aws-serverless: circleci/aws-serverless@1.0.2

今回はCircle CIパイプラインでSAMによるインフラ環境のデプロイを実行するために下記のorbを使用した。
https://circleci.com/ja/integrations/aws/

AWSのCircle CI上でのCI/CDについてはここにまとまっている
https://circleci.com/orbs/registry/orb/circleci/aws-serverless#quick-start

executors

ジョブステップの実行環境を定義し、jobごとに再使用することができる

GoのプロジェクトのCIを作成するとして、testやlintといったjobで毎回goの環境を指定するのはではなく、executorとして実行環境を定義して活用。
今回はLambda上でgoが実行されるというシステムのためdockerにはgolangのimageなどを指定した。
またSAMをつかう所以でpythonも必要。
enviromentには環境変数(goではos.Getenv()で取得できるやつ)を定義する。

version: 2.1
executors:
  go-executor:
    docker:
      - image: circleci/golang:1.13-node
      - image: circleci/python:3.6.8
      - image: XXX   
    enviroment:
      - ENV: ""
      - XXX: ""

jobs:
  my-job:
    executor: go-executor
jobs

job直下の階層は[job-name]で任意のjob名を開発者がつける。
大体はこの4つですみそう。

1. dependencies...依存関係解決(モジュールなどの取得)

  executor: go-executor
    steps:
      - run: go mod download

2. lint

  lint:
    executor: go-executor
    steps:
      - checkout
      - run: go get -u golang.org/x/lint/golint
      - run: golint ./...
      - run: go vet ./...

3. test

  test: 
    executor: go-executor
      steps:
        - checkout
        - run: go test ./...

4. build

  build:
    executor: go-executor
    parameters:
      環境変数
    steps:
      - checkout
      - run: Lambaで実行されるgoプログラムを全てビルド
      - aws-serverless/install
      - run: samのデプロイコマンドを実行
steps

step_typeと各項目
checkout: working_directoryでデフォルトとして設定したパスに戻る
restore_cache: key に設定されている内容を元に、キャッシュを復元する
- key: 復元するキャッシュキー
- keys: 復元するキャッシュキー(複数)
save_cache: CircleCIのオブジェクトストレージにある依存関係やソースコードのようなファイル、ディレクトリのキャッシュを生成し、保存
- key: キャッシュ識別用のユニークID
- paths:
run:
- name: ステップ名(CicrcleCI上で表示)
- command: シェルコマンド
- working_directory: 実行ディレクト
persist_to_workspace: Workflows の実行時に、他のジョブが使っていた一時ファイルを保持しておくための特殊なステップ
...正直必要性がわかっていない