소개

이 기사는 CircleCI Advent Calendar 2020 - Qiita의 셋째 날 기사입니다.

자신의 팀에서는 Lambda를 사용하여 배치 등을 움직이고 있습니다.
Lambda는 AWS SAM에서 관리했지만 배포를 자동화하지 않았으며 수동으로 반영했습니다.

그런 상황을 CircleCI를 사용하여 개선한 이야기를 해 나갑니다.

개선 전

개선 전 배포 흐름은 다음과 같습니다.



이 배포에는 다음과 같은 문제가있었습니다.

로컬에서 종속 해결하고 실행해야합니다

변경 세트를 검토자가 옆에서 확인해야합니다

이러한 작업을 실시하고 있기 때문에, 환경 변수의 재기록이 실수가 있거나, 더블 체크에 긴장감이 있는 상태였습니다.
개발중은 이 상태로 진행하고 있었습니다만, 프로덕션 운용을 시작하기 전에는 어떻게든 하고 싶다고 하는 생각이 있어, 자동화의 구축을 시작했습니다.

AWS SAM과 Lambda라고 하는 구성이므로, AWS Code계의 서비스로 할까 헤매었습니다만, 아래와 같이 2점으로부터 CircleCI를 선정했습니다.

다른 시스템에서 CircleCI를 사용하고 익숙합니다

도구 통합

개선 후

개선 후 배포 흐름은 다음과 같습니다.
GitHub에서 릴리스 태그를 만들면 CircleCI가 배포를 실행하는 메커니즘입니다.



의식한 포인트를 몇 가지 소개합니다.

의식이 있는 포인트

의존성 해결을 가능하게 한다

Node.js를 사용하고 있었습니다만, 원래 CD를 상정하고 있지 않고, CircleCI화하는데 있어서 대응이 필요했습니다.

구체적으로는 아래와 같이, 앱과 환경 변수의 디렉토리에 구분이 없고, 앱이 들어 있는 디렉토리내마다 package.json 가 들어가 있었습니다.
물론 monorepo는 아닙니다.

├── アプリ1
    └── package.json
├── アプリ2
    └── package.json
└── 環境変数のディレクトリ

여기는 아래와 같이 디렉토리 구조의 변경과, 쉘로 디렉토리에 cd 해 업데이트하는 것으로 해결했습니다.

├── apps
    └── アプリ1
        └── package.json
    └── アプリ2
        └── package.json
└── 環境変数のディレクトリ

monorepo도 검토했지만, 시간의 사정으로 쉘로 해결하기로 했습니다.

변경 세트를 확인할 수 있도록 설정

CloudFormation에서 --no-execute-changeset를 추가하면 미리 변경 집합을 확인할 수 있습니다.
그것은 sam-cli 에서도 같았기 때문에, --no-execute-changeset (을)를 사전에 변경 세트를 볼 수 있도록(듯이) 했습니다.

이를 통해 검토자의 변경 사항을 이해할 수 있게 되었으며 배포 승인의 두근두근을 줄일 수 있었습니다.

sam deploy (略) --no-fail-on-empty-changeset

배포는 워크플로를 구성하고 approval 이전에 실행되도록 합니다.
이렇게 하면 승인 전에 변경 집합을 확인할 수 있었습니다.

여기는 이번 개선으로 제일 잘 되었다고 생각합니다.

요약

몇 가지 궁리를 도입하여 람다의 배포를 개선할 수 있었다.
누군가의 참고가 되면 다행입니다.

참고

워크플로를 사용한 작업 일정 - CircleCI

CircleCI에서 SAM 배포