CircleCI コミュニティミートアップでLTした経緯

# はじめに
この記事は[CircleCI Advent Calendar 2020 - Qiita](https://qiita.com/advent-calendar/2020/circleci)の4日目の記事です。

CircleCIは残念ながら商用利用経験は無く、個人利用に留まっています。
縁あってCircleCIの中の人にコミュニティ運営をリードする**コミュニティリーダーグループ(大阪)**に混ぜてもらい、そろそろ活動履歴を作らねば…！との思いから先日行われた[ミートアップ](https://circleci.connpass.com/event/191289/)に登壇しました。

その登壇資料を作成する過程で得た知見を再アウトプットしようと思います。
[SpeakerDeck - CircleCI AWS-SAM-SERVERLESSを使ってみた](https://speakerdeck.com/yastani/circleci-aws-sam-serverlesswoshi-tutemita)

## ミートアップで話したこと
ざっくりこの3つです。

* CircleCI Orbs
* CircleCI + AWS
* 環境変数の設定方法

## CircleCI Orbs
CircleCIには[Orbs](https://circleci.com/orbs/)と呼ばれる**config.ymlに定義するいくつかの設定**をパッケージングして再利用ができるようになる仕組みがあります。
これを必要に応じて利用することで**Slack通知したい・AWSコマンドを叩きたい・デプロイを自動化したい**といった多くのプロジェクトで実装される要求を簡単に叶えることができるわけです。

### たとえば…CLIを使って特定のAWSコマンドを叩きたい時
下記のコードをconfig.ymlに転記してCircleCIを実行すればもう完了です。
※細かく言うと**どのAWSアカウントを対象にするか**というAWS Profileの設定はCircleCI内で必要になります

[circleci/aws-cli@1.3.1](https://circleci.com/developer/orbs/orb/circleci/aws-cli)

```yaml
version: 2.1
orbs:
  aws-cli: circleci/aws-cli@1.3
jobs:
  aws-cli-example:
    executor: aws-cli/default
    steps:
      - checkout
      - aws-cli/setup:
          profile-name: example
      - run: echo "Run your code here"
workflows:
  aws-cli:
    jobs:
      - aws-cli-example:
          context: aws
```

## CircleCI + AWS
上記のように**絶対どこかの誰かが実装してるだろう**という設定がパッケージ形式で簡単に呼び出せるというのは、CircleCIを選ぶ大きなメリットだと考えます。

登壇資料ではAWS SAMのデプロイをOrbに任せているケースを載せていますが、本記事では割愛します。
具体的にやったこととしては、[AWS SAMのチュートリアル](https://docs.aws.amazon.com/ja_jp/serverless-application-model/latest/developerguide/serverless-getting-started-hello-world.html)をOrbで書くと下記のように簡略化することができます。

[circleci/aws-sam-serverless@2.1.0](https://circleci.com/developer/orbs/orb/circleci/aws-sam-serverless)

```yaml
version: 2.1
orbs:
 sam: circleci/aws-sam-serverless@2.0.0

parameters:
 run_integration_tests:
   description: An internal flag to prevent integration local test from running before a development version has been created.
   type: boolean
   default: false

jobs:
 test_local_invoke:
   executor: sam/default
   steps:
     - checkout
     - sam/install
     - sam/local-start-api:
         template: "./sam-app/template.yaml"
         endpoint: "hello"
         debug: false
workflows:
 integration_local_test:
   when: << pipeline.parameters.run_integration_tests >>
   jobs:
     - test_local_invoke
 delivery_deploy_app_dev:
   jobs:
     - sam/deploy:
         capabilities: '"CAPABILITY_IAM"'
         name: deploy-app-dev
         template: "./sam-app/template.yaml"
         stack-name: "sam-deploy-app-dev"
         s3-bucket: "testing-orbs-yastani-dev"
         context: sam-app-dev
         filters:
           branches:
             only:
               - main

```

## 環境変数の設定方法
先述した通り、**基本的なやりたいこと**は対象となるOrbを探せば後はマニュアルに沿って自身の環境に向けることで実用化の目処が立ちます。
ですが、入門から一歩進んだところで引っかかることの一つに**環境変数の取り回し**が挙げられますね。

CircleCIでは下記のように複数の設定方法が用意されています。

* BASH_ENV を使用した環境変数
* シェルコマンドを使用した環境変数
* steps、jobs、dockerなどで使用する environment: [ key: value ]
* プロジェクトで設定する環境変数
* コンテキストで設定する環境変数
* APIを使用した環境変数
* 定義済みの環境変数

この中でも初心者の方にオススメしたい設定方法はこの2つです。

* プロジェクトで設定する環境変数
* コンテキストで設定する環境変数

これらはどちらもCircleCIの管理画面から設定することができるため非常に敷居が低く、パスワードなどの秘匿情報も意図せず公開されることがありません。

詳しい設定の手順はスライドを参照していただければと思いますが、個人的にはContextsからプロジェクト単位で必要とされる環境変数をまとめて設定することが理にかなっていると感じました。

## おわりに
正直、この登壇に向けてCircleCIを調査するまで何が良いのかよくわからなかったのですが、**実現するまでの簡便さ**や**組織内外で広く技術的知見を共有できる**というエンジニアライクを追求した姿勢を感じることができ、本当に製品のファンになりました。
まだCircleCIを試したことの無い方にこそ、既存のDevOpsツールと比較する目的でもいいので試してみてもらえれば幸いです。