Slide 1

Slide 1 text

1 と で実現する

Slide 2

Slide 2 text

2 #circlecijp

Slide 3

Slide 3 text

3 自己紹介 名前:森本 健介 / Kensuke Morimoto ポジション:Japan Country Manager 経歴:IT/Tech

Slide 4

Slide 4 text

CircleCI ● ソフトウェア開発者をターゲットに、より良いコードをより早くデリバリす るためのサービスを提供 ● 2011年に米国サンフランシスコで創業 ● 世界中に170名以上の従業員 REPRESENTATIVE CUSTOMERS

Slide 5

Slide 5 text

5 多くのユーザーにご利用頂いています

Slide 6

Slide 6 text

6 発足

Slide 7

Slide 7 text

7 日本語サポート https://circleci.jp サポート

Slide 8

Slide 8 text

8 日本語サポート https://support.circleci.com/hc/ja お問合せ

Slide 9

Slide 9 text

9 日本語サポート

Slide 10

Slide 10 text

10 日本語ドキュメント https://circleci.com/docs/ja/2.0

Slide 11

Slide 11 text

11 ユーザーコミュニティー @CircleCIJapan https://www.facebook.com/grou ps/2180735222207131/

Slide 12

Slide 12 text

12 アジェンダ 時間 内容 14:15 - 開場 14:30 - 14:45 ご挨拶とCircleCIユーザーコミュニティの紹介 by CircleCI 14:45 - 15:45 AWS と CircleCI で実現する DevOps by AWS 15:45 - 16:00 休憩 16:00 - 17:00 AWS と CircleCI で実現する DevOps by CircleCI 17:00 - 18:00 ネットワーキング

Slide 13

Slide 13 text

13 と で実現する

Slide 14

Slide 14 text

14 自己紹介

Slide 15

Slide 15 text

15 今日お話したいこと - DevOpsの歴史と重要性 - CI/CDとは何なのか - CircleCIの機能ご紹介 - CDを実現するために必要なこと - CDの例 今日話さないこと - ☓ モバイルアプリのCD

Slide 16

Slide 16 text

16 DevOpsの歴史 2001 Agile Software Development 開発対象を厳格に扱うことで変化を管理するの ではなく、アジャイル方法論は変化を許容する。 リスクは完璧な計画によって減少できるもので はなく、プロジェクトを小さく分割しつつ、それら を素早く結合させることによって減らすことがで きる。 2008 Continuous Delivery & Deployment 継続的デリバリーは継続的インテグレーションの拡張として登場。 ソフトウェアが常にデプロイ可能な状態を保つというプラクティスで ある。 責務(とリスク)を開発者と運用者の間で共有すること - DevOpsカ ルチャーの登場。 チームはテストの自動化だけではなく、テストをパスした際のデプ ロイの自動化を目指す。 1970 Waterfall 開発プロセス全体がいくつかのフェーズから構成 されていて、次のフェーズに進むためには前の フェーズを終えていなければならない。 ただし、隣接するフェーズ間の小さなイテレーショ ンは例外的に実施する場合がある。 (ハードウェアの開発方法論に似ている) 1994 Automated Testing & Continuous Integration (Inception & Evolution: 1994-2008) 開発者は、失敗をより快適なものとして捉え、それが受け入れられないものではなく、む しろ自信をつけるものになってきた。 JUnitやCucumberなどのテスティングフレームワー クの登場がそれを反映している。 マイクロプロセスの要求によって登場した継続的インテグレーション (CI)は、開発者が数 多くの内部リリースを行うことを可能にした。 すなわち、継続的インテグレーションは常に少量のコードをマージするための方法論で あり、開発の最終フェーズで競合を発生させるような巨大なコードのコミットを防ぐ 2010 - Present

Slide 17

Slide 17 text

17 継続的インテグレーションと 継続的デリバリー

Slide 18

Slide 18 text

18 CI: 継続的インテグレーション - What? 全ての開発者が共有リポジトリにコミットを積み重ね、 全てのコミットをトリガーにしてビルドとテストを繰り返すこと。 これによりテストに失敗した場合に素早く修正することが可能となる。 - Why? チームの生産性・効率・満足度を上げるため。 品質を上げ、スピードを上げ、より安定した製品を生み出すため。

Slide 19

Slide 19 text

19 でできること ● コードのビルド ● 静的コード解析 ● 単体テスト ● 結合テスト ● 脆弱性チェック ● テストサマリー

Slide 20

Slide 20 text

20 が解決する問題 ● 全てのコミットに対してCIする ○ 早い段階でバグを発見できる ○ 設定で制御可能 ● 静的解析などでの標準化 ○ コードの品質UP ● テスト失敗したコードのマージブロック ○ masterブランチの安全保証

Slide 21

Slide 21 text

21 継続的デリバリー/デプロイメント - (狭義の)Continuous Delivery (継続的デリバリー) 常にリリース可能な状態を維持する - Continuous Deployment (継続的デプロイメント) 自動でステージング・本番環境へデプロイする

Slide 22

Slide 22 text

22 自動 継続的デリバリー - リリース作業に人間の意思が介在する コードプッシュ 成果物 (JAR、TAR、 Docker Image) ステージング 本番環境 CI/CD 人間が 決定

Slide 23

Slide 23 text

23 自動 継続的デプロイメント - リリース作業に人間の意思が介在しない コードプッシュ 成果物 (JAR、TAR、 Docker Image) ステージング 本番環境 CI/CD CI/CD

Slide 24

Slide 24 text

24 とは言ってみたものの - 継続的デリバリーと継続的デプロイはいろいろな定義がありそう - 大事なのはCDを考えるときにステップを刻むこと、ステークホルダーを巻き込むこと (一足飛びに本番自動デプロイは難しい) 成果物の生成 システムテスト ステージング 自動リリース 本番環境 自動リリース 品質保証 (第三者検証) 構成管理 Blue/Green Canary 監視運用

Slide 25

Slide 25 text

25 5 Metrics You Should Know to Understand Your Engineering Efficiency https://www2.circleci.com/rs/485-ZMH-626/images/5-Key-Metrics-Engineering.pdf 1. Commit-to-Deploy Time (CDT)  コードがコミットされてからデプロイされるまでの時間 3. Queue Time  CIビルドが始まるまでに待たされる時間 2. Build Time  CIビルドに掛かる時間 5. Engineering Overhead  ツールのメンテナンスなど開発以外に掛かっている時間 4. How often Master is Red  masterブランチが壊れている時間

Slide 26

Slide 26 text

26 CircleCIのご紹介

Slide 27

Slide 27 text

27 の概要

Slide 28

Slide 28 text

28 は・・・ - Dockerをサポートしていて、高速にビルド環境を立ち上げることができ、 - .circleci/config.ymlでテスト環境を統一することができ、 - ワークフローでジョブを連結することができ、 - SSHデバッグ機能などでビルドエラーをすばやく取り除き、 - 複数のキャッシュ機構でビルドを高速化することができ、 - Orbsを使って簡単にデプロイできる

Slide 29

Slide 29 text

29 Dockerサポート - CircleCIはネイティブでDockerをサポートしています。 - VMによるCIと比べて非常に高速にビルド環境を構築することが可能です。 https://circleci.com/docs/2.0/circleci-images/

Slide 30

Slide 30 text

30 .circleci/config.ymlでテスト環境を統一

Slide 31

Slide 31 text

31 .circleci/config.ymlでテスト環境を統一 https://circleci.com/docs/2.0/sample-config/ Dockerイメージを指定 コードの取得やテスト内容を ステップとして記述 個々のジョブ定義 ジョブを組み合わせたワークフロー定義 ・連続実行 ・ファンアウト・ファンイン ・スケジューリング ・ブランチ別 ・タグ別 ...等

Slide 32

Slide 32 text

32 の思想 - コンフィグはファイルに書かれるべき (コードと同じくレビューとバージョン管理を行う) - 明示的であるべき その結果、デメリットも - 1から設定を書かないといけない - 冗長になる

Slide 33

Slide 33 text

33 ワークフロー - ビルド設定を分解して、依存関係や並列処理を行うための機能

Slide 34

Slide 34 text

34 ワークフローのタイプ ● スケジューリング: ナイトリービルドのように決まった時刻に実行 ● マニュアル承認: ワークフローの一部で自動実行を中断し、手動による承認によって再開 ● ブランチ指定: 特定のブランチへのコミットによって実行 ● タグ指定: Gitのタグによって実行

Slide 35

Slide 35 text

35 SSHデバッグ ビルドに失敗した場合など、SSHデバッグをOnにして再実行することで、 ビルド終了後2時間、もしくはSSHセッションが終わって10分間までは コンテナを起動した状態で維持します https://circleci.com/docs/2.0/ssh-access-jobs/

Slide 36

Slide 36 text

36 ビルドの高速化(キャッシュ) 同一ジョブ間のキャッシュ ワークフローが繰り返し実行される中で、同一ジョブ で利用される永続データを使い回す。 同一ワークフロー内のキャッシュ 同一ワークフロー内の異なるジョブ間でデータを共 有する。

Slide 37

Slide 37 text

37 ビルドの高速化(並列処理) 4並列でそれぞれ10個のテストを実行 https://circleci.com/gh/kurumai/circleci-step-by-step/210

Slide 38

Slide 38 text

38 設定のパッケージングと再利用( ) - Orbsとは、CircleCIの設定を再利用し、さらにそれを自由に配布する仕組み - Orbsを使うと他の人が書いたCircleCIの設定を自分のプロジェクトの .circleci/config.yml に差し込むことができる。 - OrbsはOrbsレジストリ上で誰でも公開することができ、他のユーザーが作ったOrb を誰でも使うことが可能

Slide 39

Slide 39 text

39 の種類 - Orbs Registry https://circleci.com/orbs/registry/ - Certified (CircleCI) - Partner (CircleCI認定パートナー) - 3rd party (その他)

Slide 40

Slide 40 text

40 で を 実現するためには

Slide 41

Slide 41 text

41 継続的デプロイに必要なこと(機能面) - アーティファクト(成果物)がきっちり管理されていること - 品質が自動的・機械的に確認できること - CIの延長線上で実行できること - デプロイに必要なトークンなどの情報が秘匿できること - デプロイ設定がコンフィグとして管理できること - ダウンタイムを最小にできること - 切り戻しが容易であること その他、DevOpsを実現するためには、 モニタリングを含めたシステム運用・サービス運用が必要

Slide 42

Slide 42 text

42 継続的デプロイに必要なこと - アーティファクト(成果物)がきっちり管理されていること - 品質が自動的・機械的に確認できること - CIの延長線上で実行できること - デプロイに必要なトークンなどの情報が秘匿できること - デプロイ設定がコンフィグとして管理できること - ダウンタイムを最小にできること - 切り戻しが容易であること CircleCI AWS

Slide 43

Slide 43 text

43 秘密情報の管理 - CircleCIでは、環境変数とContextsという2つの機能で、プロジェクト内の秘匿情 報、プロジェクトをまたいだOrganizationレベルの秘匿情報を管理することができま す。 - 環境変数: https://circleci.com/gh/kurumai/circleci-step-by-step/edit#env-vars - Contexts: https://circleci.com/gh/organizations/kurumai/settings#contexts/be4f6a40- 731a-43e3-a7ed-d216b18cc12b -

Slide 44

Slide 44 text

44 利用イメージ ● CircleCIの画面から環境変数を設定して、config.ymlのechoで環境変数を利用

Slide 45

Slide 45 text

45 デプロイ定義をコンフィグに書く CodeDeployとかAPIを直接書いても 良いけど大変そう・・・ そこでOrbs!!

Slide 46

Slide 46 text

46 関連の

Slide 47

Slide 47 text

47 例えば にプッシュしつつ へデプロイしたい

Slide 48

Slide 48 text

48 準備 環境変数の設定 APIキーとパスを環境変数から登録しておく

Slide 49

Slide 49 text

49 version: 2.1 orbs: aws-ecr: circleci/[email protected] # ECRのOrbをインポート workflows: build-and-deploy: jobs: - aws-ecr/build_and_push_image: # 用意されているジョブにパラメータを渡して呼ぶ account-url: AWS_ECR_ACCOUNT_URL # ECRのアカウントの環境変数 repo: 'nginx' # イメージのレポジトリ tag: '${CIRCLE_SHA1}' # イメージのタグにコミットの SHAを使う へ イメージのデプロイ

Slide 50

Slide 50 text

50 version: 2.1 orbs: aws-ecs: circleci/[email protected] # ECSのOrbをインポート workflows: build-and-deploy: jobs: - aws-ecr/build_and_push_image: ... - aws-ecs/deploy-service-update: # 用意されているジョブにパラメータを渡して呼ぶ requires: - aws-ecr/build_and_push_image # 最初にnginxイメージをビルド family: 'kim-app-nginx' # ECSのタスク定義 cluster-name: 'default-kim5' # ECSのクラスター名 # タスクで使うコンテナイメージを指定 container-image-name-updates: 'container=nginx,image-and-tag=833371238208.dkr.ecr.us-east-1.amazonaws.com/nginx:${CIRCLE_SHA1}' へサービスのデプロイ

Slide 51

Slide 51 text

51 を使うことで コンフィグの削減量 370行 → 20行

Slide 52

Slide 52 text

52 継続的デプロイに必要なこと(再掲) - アーティファクト(成果物)がきっちり管理されていること - 品質が自動的・機械的に確認できること - CIの延長線上で実行できること - デプロイに必要なトークンなどの情報が秘匿できること - デプロイ設定がコンフィグとして管理できること - ダウンタイムを最小にできること - 切り戻しが容易であること CircleCIとAWSを組み合わせることで、 CI/CDを簡単に始めることができます!!

Slide 53

Slide 53 text

53 ハンズオンセミナー - ConnpassのCircleCIグループをフォローしてお待ち下さい!!

Slide 54

Slide 54 text

Thank you. 54 Optional Name

Slide 55

Slide 55 text

55