kakakakakku blog

Weekly Tech Blog: Keep on Learning!

CodeDeploy のデプロイ実行とデプロイ完了待機を AWS CLI で試した

CodeDeploy のデプロイ実行を AWS CLI で試した.今回は GitHub からコードを取得する前提にしている.

コミットハッシュを取得する

CodeDeploy で GitHub からコードを取得する場合,対象となるコミットハッシュが必要になる.そこで,GitHub API から指定したブランチの最新コミットハッシュを取得する.また,プライベートリポジトリの場合はアクセストークンが必要になるため,Authorization ヘッダーに乗せている.

公式ドキュメントに載っている通り,以下のようなレスポンスが返ってくるので,sha からコミットハッシュを取得することができる.

{
  "ref": "refs/heads/featureA",
  "node_id": "MDM6UmVmcmVmcy9oZWFkcy9mZWF0dXJlQQ==",
  "url": "https://api.github.com/repos/octocat/Hello-World/git/refs/heads/featureA",
  "object": {
    "type": "commit",
    "sha": "aa218f56b14c9653891f9e74264a383fa43fefbd",
    "url": "https://api.github.com/repos/octocat/Hello-World/git/commits/aa218f56b14c9653891f9e74264a383fa43fefbd"
  }
}

デプロイを実行する

AWS CLI でデプロイを実行する場合 aws deploy create-deployment を使う.ポイントはコミットハッシュの指定で,github-location オプションを以下のフォーマットで指定する.

repository=string,commitId=string

デプロイの完了を待つ

aws deploy create-deployment は,デプロイを実行するだけなので,デプロイの完了を待つ aws deploy wait deployment-successful と組み合わせて使う.aws deploy create-deployment のレスポンスに以下のような deploymentId が含まれているので,これを指定する.

{
    "deploymentId": "d-N65YI7Gex"
}

サンプルコード

最後にサンプルコードを貼っておく.実際に実装したコードはもっと複雑だけど,今回は単純化している.

実行

export BRANCH_NAME='master'
sh deploy.sh

deploy.sh

#!/bin/sh

#######################################
# 指定したブランチの最新コミットハッシュを取得する
# Arguments:
#   $1 BRANCH NAME
# Returns:
#   COMMIT HASH
#######################################
get_commit_hash() {
  curl -s -H "Authorization: token xxx" \
    https://api.github.com/repos/xxx/xxx/git/refs/heads/$1 | jq  -r '.object.sha'
}

#######################################
# デプロイを実行する
# Arguments:
#   $1 BRANCH NAME
# Returns:
#   DEPLOYMENT ID
#######################################
create_deploy() {
  echo $(
    aws deploy create-deployment \
      --application-name xxx \
      --deployment-group-name xxx \
      --github-location repository=xxx/xxx,commitId=$(get_commit_hash $1) \
      --deployment-config-name CodeDeployDefault.OneAtATime \
      --region ap-northeast-1 | jq -r '.deploymentId'
  )
}

#######################################
# デプロイの完了を待つ
# Arguments:
#   $1 DEPLOYMENT ID
#######################################
deploy_waiter() {
  aws deploy wait deployment-successful --deployment-id $1
}

deployment_id=$(create_deploy ${BRANCH_NAME})
echo "deploymentId: ${deployment_id}"

deploy_waiter ${deployment_id}

CodeDeploy 関連記事

kakakakakku.hatenablog.com

モブプログラミングに特化したタイマーアプリ「Mobster」

モブプログラミングをするときに,モブセッションの時間を意識することが重要で,事前に準備しておく MDE (Mob Development Environment) の中にも「Timer」が含まれている.シンプルにスマホのタイマーアプリを使っているチームも多い気がする.

kakakakakku.hatenablog.com

Mobster とは?

そこで今回は,モブプログラミングに特化したタイマーアプリの「Mobster」を紹介する.アプリは OSS で公開されているので,実装を読むこともできる.

github.com

Mobster : ドライバーとナビゲーターを設定できる

「Active」のところにある「+ Mobster」フィールドから,モブプログラミングに参加するドライバーとナビゲーターを設定できる.ドライバーには青く「ハンドルアイコン」が付き,ナビゲーターには「地図アイコン」が付く.Mobster だと,2人目のナビゲーターには「地図アイコン」が付かず,なぜ?という疑問はある.メインナビゲーターのような感じなのかな?

さらに「サイコロ」アイコンを押すと,ドライバーを自動的に選ぶことができる.ドライバーを挙手制にすると,ある程度,心理的な影響が出る場合もあるので,自動的に選べるのは便利だと思う.

f:id:kakku22:20180701165208p:plain

Mobster : モブセッション時間を設定できる

上のキャプチャにある通り,モブセッション時間と休憩時間を設定できる.僕のチームでは「ポモドーロテクニック」を採用しているので「25 + 5」という設定にしている.

Mobster : タイマーが画面右下に表示される

「Start Mobbing」のボタンを押すと,下のキャプチャにある通り,画面右下にタイマーが表示されて,常に意識しながらモブプログラミングを進めることができる.また,右下のアイコンを押すときなどは,自動的に左下にタイマーが移動するので(試してみるとわかる),そのあたりのイライラもなかった.ただし,Mac のフルスクリーン機能を有効にすると,タイマーが別のウィンドウに飛んでしまう場合があるので,ここはちょっと微妙な感じだった.

f:id:kakku22:20180701165224p:plain

Mobster : 離席できる

モブプログラミングは,全員参加を強制するものではなく,ナビゲーターは自由に離席することができるため,Mobster には「Away」ボタンがある.「Away」ボタンを押すと,Inactive に入るので,ドライバーとナビゲーターに選ばれなくなる.このあたりは,モブプログラミングに特化しているなと感じる.

f:id:kakku22:20180701165239p:plain

Mobster : Learn to mob game

メイン画面に「Learn to mob game」というボタンがあり,もしかしたらゲーミフィケーションでモブプログラミングを学べるのかな?と思ったけど,特にそんなこともなく,普通に Mobster が動くだけで残念だった.もしくは他の用途がある?

メリット/デメリット

Mobster はモブプログラミングに特化したタイマーアプリなので,ドライバーとナビゲーターを登録できたり,タイマーがエディタ上に表示されたり,非常に便利に使えると思う.ただし,前回の記事にも書いた通り,僕のチームでは MDE (Mob Development Environment) を揃えてなく,ドライバーのマシンを使う運営を推奨しているので,ドライバーごとに Mobster の設定をするのが手間になり,結局使わなかった.もし今後,統一の MDE (Mob Development Environment) を用意する場合は,Mobster を使おうと思う.

ウェブタイマー

現在の運営だと,タイマー専用のマシンをディスプレイの横に置いて,そこでウェブタイマーを動かしている.シンプルな機能で十分なので,以下のウェブタイマーを使っている.

モブプログラミングの基礎を学べる洋書「Getting Started with Mob Programming」を読んだ

今年3月頃から,チームにモブプログラミングを導入している.「スウォーミング(共同作業)」「フロー効率(着手している作業を最速で終わらせること)」を文化に根付かせることと,技術的な強さを伝播させる狙いで導入して,今のところ多くのメリットを感じられているけど,ベストプラクティス(もしくは基本型)を学んでみたく,Leanpub で購入できる電子書籍「Getting Started with Mob Programming」を読んだ.非常に良かったので,学んだことを整理して紹介したいと思う.

f:id:kakku22:20180629191234p:plain

追記 : Code with the Wisdom of the Crowd

本書「Getting Started with Mob Programming」は,2018年末頃に Leanpub で販売中止になってしまった.現在は同じ著者が出版した「Code with the Wisdom of the Crowd」を読むと良さそう.類似した内容になっている.

pragprog.com

目次

  • Part I - Before you start
    • 1 What is Mob Programming?
    • 2 Frame Mob Programming as an experiment
  • Part II - Getting to your first mob session
    • 3 Where to mob first?
    • 4 What should you work on?
    • 5 How big should the mob be?
    • 6 When & how long should the first session be?
    • 7 Preparing the development environment
  • Part III - Your first mob session
    • 8 Outline for the session
    • 9 Explain the roles to the group
    • 10 Determine the order for rotating typists
    • 11 Start the first interval and mob for ten minutes
    • 12 Rotate typists and start the next interval
    • 13 The closing retrospective
    • 14 Forming, storming and conflict
  • Part IV - Gaining momentum
    • 15 Your next few mobbing sessions
    • 16 When only one person knows…
    • 17 When nobody knows…
    • 18 Getting rhythm with core mobbing time
    • 19 A permanent place to mob
    • 20 Getting a mob station
    • 21 Where to from here?

モブプログラミングのテーマを選ぶときの条件

本書では「全ての仕事がモブプログラミングに適しているわけではない」という前提で,以下の条件を満たすテーマを見極めることが重要と書かれていた.個人的には「フロー効率」を意識しているので,期限も意識していて,ここは言い過ぎないようにしないとなーと感じた.

  • It should be interesting(楽しそう)
  • Everyone should be able to contribute(貢献したい)
  • It should be small, but not too small(小さすぎず,小さく)
  • It should not have a tight deadline(タイトな期限がないこと)
  • It should not be overly complex or simple(簡単すぎず,難しすぎず)

モブプログラミングに適切な人数

本書では「3-8人」が良いと書かれていて,特に「4人」がベストと書かれていた.理由としては「3人」だと,ミーティング/体調不良などで1人不在になると「ペアプログラミング」になってしまう点が問題で,「5人以上」だと必要以上に「ストーミング」が起きてしまう点が問題だと書かれていた.「ストーミング」とは「タックマンモデル」に出てくるもので,組織の成長に必要な「対立」のことを意味している.必要だからこそ,人数が多すぎると必要以上に「対立」が起きてしまうと書かれていて,個人的には納得できた.

モブプログラミングに必要な役割の名称

一般的には,モブプログラミングの役割は「ドライバー」「ナビゲーター」と呼ぶけど,本書ではあえて呼ばず,以下の用語で統一されていた.理由としては「メタファーは適切ではないから」と書いてあったけど,個人的にここはあまり納得できていなく,むしろわかりにくくなっているように感じた.なので,記事の中では「ドライバー」と「ナビゲーター」に統一している.

  • the typist(ドライバーと同義)
  • the rest of the mob(ナビゲーターと同義)

モブセッションの時間

最初は「1時間半」から始めるのが良いと書かれていた.そして「1時間半」を分割するときに,スキルレベルによって時間を短くするのも有効と書かれていた(例えば,新人は「15分」など).僕のチームでは「ポモドーロ(25分 + 5分)」でモブセッションをローテーションしている.また「時間を守る,時間を伸ばしすぎないこと」も重要と書かれていた.

MDE とは?

モブプログラミングをする環境のことを,本書では MDE (Mob Development Environment) と表現していて,以下の5種類が紹介されていた.

  • エディタ
  • キーボードショートカット
  • コードナビゲーション
  • バージョン管理ツール用アカウント
  • タイマー

モブプログラミングの基本型では,チームで1台のマシンを使うので,エディタもショートカットも一般的なものに揃えておくと良いと書かれていた.例えば,チーム全員で IntelliJ を使うなど.あと vim の話もあり,他のメンバーの学習コストが高いので,避けるべきと書かれていた.また個人的に興味深かったのは,モブプログラミング用のバージョン管理ツール用アカウントを作るという話だった.確かに GitHub のコミットログを見たときに,モブプログラミングなのに特定のメンバーのコミットになっていると,モチベーションが下がってしまう.

個人的には,エディタも,ショートカットも,キーボードなどの周辺機器も,揃えるのが難しいと考えているので(例えば,僕は HHKB が必須だったりする),僕のチームではモブセッションごとにドライバーのマシンを接続している.ディスプレイに接続するアダプタとして「HDMI / USB-C / Thunderbolt」を用意しておけば,ほぼ大丈夫なので,そこまで強制しなくて良いように思う.

割り込みを排除する

本書で何度も出てくる「モブプログラミングはフローである ( A big aspect of Mob Programming is flow )」という表現がとにかく好きで,だからこそ,そのフローに割り込まないようにするべきという話題もあった.例えば,途中のモブセッションに参加していなかったメンバーが戻ってきたときに「その後どう?」と聞くのはダメで,静かにモブセッションに参加して,状況を読み取るべきと書かれていた.また,スマホの通知を受けるとコンテキストスイッチが起きるので,それも気をつけるべきと書かれていた.僕のチームでは,基本的には Slack を落としてもらう工夫をしている.

まとめ

記事に書いたこと以外にも,モブプログラミングを運営していて気になっていたことを多く学ぶことができた.ベストプラクティス(もしくは基本型)に完全にハマる必要はないので,チームごとにカスタマイズをするべきだと思うけど,だからこそベストプラクティス(もしくは基本型)を学んでおくべきかなと思う.これからモブプログラミングを導入しようと考えている人,モブプログラミングを導入しているけど,うまく運営できていない人,モブプログラミングのファシリテーションを担当している人などにオススメ!

CodeDeploy エージェントのログに Missing credentials と出たら codedeploy-agent を再起動する

最近 CodeDeploy の検証をしていて,codedeploy-agent のエラーログに少しハマったので,メモ程度に残しておく.

aws.amazon.com

Amazon Linux に codedeploy-agent をインストールする

公式ドキュメントに書いてある手順で,問題なくインストールできた.

$ wget https://aws-codedeploy-ap-northeast-1.s3.amazonaws.com/latest/install
$ chmod +x ./install
$ sudo ./install auto
$ sudo service codedeploy-agent status
The AWS CodeDeploy agent is running as PID 29095

IAM Role を割り当てる

CodeDeploy を使う場合,2種類の IAM Role を作る必要がある.今回は公式ドキュメントの通りに設定をした.

  • CodeDeploy に割り当てる IAM Role
  • EC2 に割り当てる IAM Role

docs.aws.amazon.com

docs.aws.amazon.com

エラーログ : Missing credentials

次に codedeploy-agent のログファイル /var/log/aws/codedeploy-agent/codedeploy-agent.log を見ると,以下のようなエラーログがずっと出ていた.

2018-06-25 22:44:53 INFO  [codedeploy-agent(8311)]: Version file found in /opt/codedeploy-agent/.version with agent version OFFICIAL_1.0-1.1518_rpm.
2018-06-25 22:44:53 ERROR [codedeploy-agent(8311)]: InstanceAgent::Plugins::CodeDeployPlugin::CommandPoller: Missing credentials - please check if this instance was started with an IAM instance profile
2018-06-25 22:46:23 INFO  [codedeploy-agent(8311)]: Version file found in /opt/codedeploy-agent/.version with agent version OFFICIAL_1.0-1.1518_rpm.
2018-06-25 22:46:23 ERROR [codedeploy-agent(8311)]: InstanceAgent::Plugins::CodeDeployPlugin::CommandPoller: Missing credentials - please check if this instance was started with an IAM instance profile

Missing credentials - please check if this instance was started with an IAM instance profile と出ているので,EC2 に割り当てた IAM Role 関連だなーと思ったけど,何度見直してもうまく割り当たっていて,最終的に codedeploy-agent を再起動したら解決した.ウッ!

$ sudo service codedeploy-agent restart
Restarting codedeploy-agent:

まとめ

今回インスタンスを起動してから IAM Role を割り当てたので,順番が良くなくて,無駄にハマってしまった.「IAM Role を後から割り当てる場合は codedeploy-agent を再起動する」と覚えておくと良さそう.引き続き CodeDeploy を検証するぞ!

(問題解決済)暫定対応 : はてなブログに Speaker Deck のスライドを埋め込むとデザインが崩れる件

2021年11月 : 追記

2021年10月時点で 3. 横幅が狭い環境でも Speaker Deck のスライドを正しい縦横比で表示されるようにしました とあるため,問題解決になったようです.詳しくは以下の記事を参照で!📝

staff.hatenablog.com

(追記ここまで)


今月,Speaker Deck の運営会社が GitHub から Fewer and Faster LLC に変更になり,同時にデザインも大幅にリニューアルされた.それに伴って,はてなブログに Speaker Deck のスライドを埋め込むとデザインが崩れる場合がある.具体的に言うと,幅の設定が悪く,以下のように,両サイドが切れてしまう(特にスマホだと顕著になる).

PC

f:id:kakku22:20180625113219p:plain

スマホ

f:id:kakku22:20180625113234p:plain

暫定対応

「はてなブログの埋め込み」を使わずに「Speaker Deck の Embed スクリプト」を使う.以下の「Copy embed code」ボタンを押すと,以下のスクリプトがコピーされるので,これをそのまま貼り付ければ,オッケー!ただし,公開中の全ての記事を修正するのは不可能なので,あくまで暫定対応として使う必要がある.

<script async class="speakerdeck-embed" data-id="bfa7e39dbe3540cc81c87a300986abc1" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>

f:id:kakku22:20180625113247p:plain

暫定対応をすると,以下のように,正常に見れるようになる.

PC

f:id:kakku22:20180625113306p:plain

スマホ

f:id:kakku22:20180625113325p:plain

oEmbed

今回の根本原因は Speaker Deck の oEmbed で,現時点では Speaker Deck 側に問い合わせている状況なので,概要だけをまとめておく.

「はてなブログの埋め込み」を使うと,Speaker Deck のスライドは,以下の「はてな記法」に変換される.

[https://speakerdeck.com/kakakakakku/project-leading-is-skill:embed:cite]

この「はてな記法」は oEmbed の仕様に沿って変換されていて,Speaker Deck の HTML を見ると,head タグに以下のような link タグがある.

<link rel="alternate" type="application/json+oembed" href="https://speakerdeck.com/oembed.json?url=https%3A%2F%2Fspeakerdeck.com%2Fkakakakakku%2Fproject-leading-is-skill" title="プロジェクトをリードする技術 / Project Leading is Skill">

そして,href にある Speaker Deck のエンドポイントを叩くと,以下のレスポンスが返ってくる.このレスポンスにある iframe のパラメータが,今回の根本原因だと思う.

{
"type": "rich",
"version": 1,
"provider_name": "Speaker Deck",
"provider_url": "https://speakerdeck.com/",
"title": "プロジェクトをリードする技術 / Project Leading is Skill",
"author_name": "Yoshiaki Yoshida",
"author_url": "https://speakerdeck.com/kakakakakku",
"html": "<iframe id=\"talk_frame_440345\" src=\"//speakerdeck.com/player/bfa7e39dbe3540cc81c87a300986abc1\" width=\"710\" height=\"463\" style=\"border:0; padding:0; margin:0; background:transparent;\" frameborder=\"0\" allowtransparency=\"true\" allowfullscreen=\"allowfullscreen\" mozallowfullscreen=\"true\" webkitallowfullscreen=\"true\"></iframe>\n",
"width": 710,
"height": 463
}

Speaker Deck に問い合わせているので,返事があり次第,まだ続報を書こうと思う.

まとめ

はてなブログに Speaker Deck のスライドを埋め込むと,デザインが崩れてしまう.暫定対応として「Speaker Deck の Embed スクリプト」を使おう!