(Beta)clean release manual

114年2月16日日曜日

こんな経験ありませんか？


「XXの運用作業お願い」


「はーい！」


とは言ったもののやったことないから

前の手順を探してみるかー


それっぽいのあった！！


とりあえず参考にしながらやってみるお!!


「あれ!?」814年2月16日日曜日

パス違うじゃん



コマンド打ったけどこの結果でいいの？



このコマンド何したいんだろう？


!?1414年2月16日日曜日


みなさんが怒りのあまり武丸さんにならない為に


うわ・・・私の手順書、しょぼすぎ！？>>あなたの手順スキルは？

ってならない為に1714年2月16日日曜日

リリース手順書の最低限のマナーについて


マジメにお話ししてみます。


題しまして、


CleanRelease Manualクリーンリリースマニュアル TAKAKING22　著

及部敬雄　訳

http://www.flickr.com/photos/16983197@N06/6806402045/

β2114年2月16日日曜日



この話のターゲットは

全員2214年2月16日日曜日

リリース手順書を書く書かないではなく、


他人と働く上で大切なポイントは同じ

ハズ


他人と働く上で大切なポイントは同じ

そもそもプロダクトコード書いててプロダクトをリリースできないって・・・(ry



1.リリース手順書- 定義と心構え -




の前に“手順書”とは？


“ ある条件に対応する方法を　知らない者（初心者）に対して　示し、教えるための文書である ”

/ wikipedia先生

手順書＝マニュアル


“ ある条件に対応する方法を　知らない者（初心者）に対して　示し、教えるための文書である ”

/ wikipedia先生

手順書＝マニュアル


手順書3014年2月16日日曜日

手順書には相手がいる


そしてその相手は入社してきたばかりの新人かもしれない


次の●●に当てはまる言葉を答えなさい


リリース●●本番●●運用●●


リリース作業本番作業運用作業


作業3614年2月16日日曜日

作業と仕事の違い


作業は与えられた指示にそって何かを行うこと仕事は目的があり

その目的の達成のために考えて行動すること


作業は、考えなくてもできる（ようにすべき）


作業は、ロボットでもできるだから自動化できる


リリース手順書


作業者が初心者でも、考えずに作業が実施できるように文書化

したもの





2.リリース手順書の必要条件




takaking22MacBookPro:work oyobe$ ls -latotal 8drwxr-xr-x 3 oyobe staff 102 1 29 06:31 ./drwx------@ 30 oyobe staff 1020 1 29 06:30 ../-rw-r--r-- 1 oyobe staff 53 1 29 06:31 release_manual.txt

takaking22MacBookPro:work oyobe$ chmod 744 release_manual.txt

takaking22MacBookPro:work oyobe$ ls -latotal 8drwxr-xr-x 3 oyobe staff 102 1 29 06:31 ./drwx------@ 30 oyobe staff 1020 1 29 06:30 ../-rwxr--r-- 1 oyobe staff 53 1 29 06:31 release_manual.txt*

takaking22MacBookPro:work oyobe$ ./release_manual.txtReleasing now....Release complete!!

以下でリリースできること






以下でリリースできること

手順書に実行権限つけて、

実行したらリリースできる！


ここまでは言いませんが、最低でも・・・


リリース手順書の必要条件上から下までコピペして実行するだけの簡単な作業をすればリリースが完了すること


パスミス実行できない

意図がわからない

必要条件を満たしてない


めんどくせーなー自動化すればいいじゃん

って思ってるあなた


その通り!!


でも自動化するってことはひらたく言えば、






こういう手順が作れること

手順書に実行権限つけて、

実行したらリリースできる！


リリース手順書がまともに書けない輩は


自動化って軽々しく言うな

自動化



3.リリース手順書を書く(基本編)




基本はたった１つ


1. 変化前のチェック2. 変化3. 変化後のチェック


pwd# /home/oyobe であること

cd /home/oyobe/work

pwd# /home/oyobe/work であること

変化前のチェック（現在地の確認）

変化後のチェック（現在地が変わった）

変化（移動する）

ディレクトリの移動


ls -la hogehoge# hogehoge が存在しないこと

touch hogehoge

ls -la hogehoge# hogehoge が存在すること

ファイル新規生成変化前のチェック（ファイル存在ない）

変化後のチェック（ファイルが存在する）

変化（ファイルをつくる）


diff hogehoge2 hogehoge# 以下の差分があること# 3d2# < Tommorow, we can see his magic!!

cp hogehoge2 hogehoge

diff hogehoge2 hogehoge# 差分がないこと

変化前のチェック（差分があること）

変化後のチェック（差分が無いこと）

変化（ファイルを更新）

ファイル更新


crontab -l | diff crontab.new -# 以下の差分があること# 5d4# < * * * * * /etc/OsakiMagic.sh

crontab crontab.new

crontab -l | diff crontab.new -# 差分がないこと

変化前のチェック（差分があること）

変化後のチェック（差分が無いこと）

変化（crontabを更新）

crontab更新


この繰り返しでリリースできるハズ


1. 変化前のチェック2. 変化3. 変化後のチェック

だからこれだけは、

絶対にさぼらない!!6514年2月16日日曜日

意図を持って書く


意図を持つ•期待値の明記•コマンドのオプション•絶対パス／相対パス




pwd# /home/oyobe であること

ls -la hogehoge# hogehogeが存在すること# ファイル権限が744であること

crontab -l | diff crontab.new -# 以下の差分があること# 5d4# < * * * * * /etc/OsakiMagic.sh

期待値を明記する# 始まりで書けば、

間違って実行しても大丈夫

期待値を誰が見ても迷わないように書く

差分を書いてあげると迷わないよね！




cp -p hogehoge ~/work/

cp -i hogehoge ~/work/

ls -ld ~/work

diff -r foo bar

rm -rf hogehoge

コマンドのオプション

全部わかりますか？7114年2月16日日曜日

cp -p hogehoge ~/work/

cp -i hogehoge ~/work/

ls -ld ~/work

diff -r foo bar

rm -rf hogehoge

コマンドのオプション権限、タイムスタンプそのまま

更新の場合、確認あり

ディレクトリの詳細情報

ディレクトリの差分確認

ディレクトリ強制消去


暗記しなくていいけどオプションは

意図して選択する




cd /home/oyobe/work

cd ./work

絶対パス / 相対パス


cd /home/oyobe/work

cd ./work

絶対パス / 相対パス絶対パス

相対パス

現在地を気にせずに使える

現在地を気にして使う


rm -rf ${WORK_DIR}/*

rm -rf ./work/*

絶対パス / 相対パス

もし現在地を間違えても同じディテクトリ名がなければ消えない

環境変数の設定を間違えると思わぬものが消えるかも


リハーサルは必須


ここまでは最低限


＋α


手順書には相手がいるリリーサー？

チームメンバー？レビュワー？未来の後輩？


“相手”のことを考えてリーダブルにシンプルに書く


diff -br /foo/bar/test /yama/kawa/# 差分があることcp -p /foo/bar/test /yama/kawa/.diff -br /foo/bar/test /yama/kawa/# 差分が無いこと

インデントをそろえる

読みやすいし、パスを間違えてたら一目でわかる


bashexport WORK_TIME=`date +%Y%m%d`export WORK_DIR=${HOME}/work/${WORK_TIME}export APP_BASE_DIR=/usr/local/rms/jerry/recipe

diff -br ${WORK_DIR}/test ${APP_BASE_DIR}/hoge/# 差分があることcp -i ${WORK_DIR}/test ${APP_BASE_DIR}/hoge/diff -br ${WORK_DIR}/test ${APP_BASE_DIR}/hoge/# 差分が無いこと

長過ぎるパスをまとめる

文字数が減る、画面幅におさまる


お・も・い・や・り



4.リリース手順書を書く(応用編)





5.こんな手順はいやだ(実例)




【正式版】Clean Release Manual乞うご期待!!



5.読者の皆様へ




http://www.amazon.co.jp/gp/product/4822249212/

機械との競争エリック・プリニョルフソン、アンドリュー・マカフィー共著日経BP社出版




“Race against the Machine （機械との競争）に希望はなく、 Race with the Machine （機械をもってする競争）へと考えを転換する必要がある”

/ 機械との競争


サービス指向スタートアップ指向

も重要


リリース自動化Continuous Delivery

も大事


でもその前に


あなたの書いた手順書は大丈夫ですか？


相手のことを考えて


一緒に働いてる仲間や未来の後輩のために


キレイでシンプルなリリース手順書を書くことができる


リリースを当たり前にしてプロダクトの価値

の最大化に注力できる


それができてこそサービサー

じゃないでしょうか？


作業を当たり前にして自動化して楽をして

次の新しい事に挑戦する


それができてこそエンジニア

じゃないでしょうか？


あなたも書こう！


CleanRelease Manualクリーンリリースマニュアル TAKAKING22　著

及部敬雄　訳

http://www.flickr.com/photos/16983197@N06/6806402045/10414年2月16日日曜日



及部敬雄@TAKAKING22

●楽天株式会社開発ユニット●新サービス開発・運用1課●歌って踊れるエンジニア●アイドル、アニメに精通


Technology

(Beta)clean release manual