00:07
はい、1月30日、火曜日ですね。 遅刻は昨日もありました。
本日は高知にいます。 本日もですね、高知駅のとあるホテルで今配信をしています。
はい、おはようございます。 keethのふわはらです。
本日も朝活をやっていきたいかなと思います。
ちょっと、急遽とったホテルなので、 外音ですかね、周りの環境音がうるさいので、
僕の声の質がかなり低いとは思いますが、 ちょっと応用していただければ幸いです。
じゃあ本日もタイトルにありますね。
Shipping to Productionという記事ですね。 3日に分けて書けて読んでますけど、
これの、多分今日で終わるんじゃないかなと思いますので、 読み切っていきたいなと思います。
では行きましょう。
市中郵船さんとKさんですね。 おはようございます。
今日もご参加いただきありがとうございます。
今日でも短めに終わるかもしれないですね。
これ終わったらそのまま東京に帰る予定なので、
電車の予約した指定席に間に合うように ちょっと急ぎたいと思うので、
ちょっと短めに終わるかもしれないです。
では行きましょう。
Shipping to Productionの5つの項目のラストですね。
Taking Programmatic Risk to Move Fasterですね。
というところから今日は入っていきたいかなと思います。
はい、じゃあ行きましょう。
より早く動くために現実的なリスクを取るというタイトルですね。
通常よりも早く移動したい。
そのためにもう少しリスクを取っても構わないという場合があります。
そのための実用的なプラクティスとは何でしょうか。
どのプロセスやツールを絶対に返してはいけないかみたいなのを決めますと。
テストを実行せずに強制的に着陸するということが可能か。
コードベースの変更を他の誰にも見られずにいけますかと行いますか。
テストなしで本番用データベースを変更することは可能かみたいな問いを挙げられてますね。
こんな問いからどのプロセスとかツールを使わなきゃいけないか。
もしくは避けなきゃいけないかというのを決めましょうと言ってますね。
どのプロセスを迂回できないかを決めるのは全てのチームあるいは会社にかかっています。
同期の全ての例について、もしこの質問が製品に依存している多くのユーザーを持つ成熟した会社でできた場合。
私はルールを破る前に慎重に考えるでしょう。
これは利益よりも害をもたらすかもしれません。
それはあるかもしれないですね。
結構成熟したプロダクトを持っているもしくは大きい会社でやるんだったら、
それは皆さん慎重に考えるでしょう。
物によっては利益よりもそうですね。
障害一発起こしただけで一気に赤字になる可能性もあるのでね。
もしより早く進めるためにルールを回避することを決めたのであれば、
その行動に出る前にチームの他の人たちのサポートを受けることをお勧めします。
要はレビュー受けろってことだと思います。
では具体的に入っていくんですけど、
03:01
リスクの高い変更を出荷する時は関連するステークホルダーに注意をまず喚起します。
時よりリソードするよりもリスクが高くテストが十分でない変更を出荷することもありますが、
何かおかしなことが起きたら、
あなたに警告してくれるかもしれない人たちに注意を流しておくのが良い習慣にありますよと。
このような場合に通知する価値のあるステークホルダーとは以下の通りです。
5つの項目がありますね。
1人目はチームメンバーです。
2つ目があなたのチームに依存しているチームのオンコール、
およびあなたが依存しているチームのオンコールですね。
3つ目がユーザーが接触する顧客向けの利害関係者。
4つ目がカスタマーサポート。
最後にビジネス指標にアクセスでき何か悪い方向に進んでいると判断した場合に通知できるビジネス的な利害関係者。
この辺ですね。
最初から通知をしておくとか、
事前に注意を流しておくのが良いことかもしれないですね。
あとは簡単に実行できるロールバックプランというのをちゃんと用意しておきましょうと。
これはそうですよね。
問題が発生した変更をどのように元に戻せば良いのか、
たとえ動きが速くても実行しやすい計画を立ててくださいと。
これはデータの変更と構成の変更において特に重要ですということですね。
ロールバックのシビアというかコアなところで結局多分データベースになると思いますね。
データをいかに元に戻すことができるかというところが割と重要だと思うので、
ここをミスなくかつスピード速くロールバックできるような
用意をしておくというのが結構重要だと思います。
あとはミスがあったとしてもそれも全部ログに出しておくのも結構大事ですよね。
後で分析したり対策したりできるので、
しっかりログを取っておくというのも重要かなと思いました。
ここですね。
またまたFacebookの例を出すんですけど、
Facebookの時には差分ファイルにリバートプラントというものを追加することが一般的だったらしいですね。
Facebookのエンジニアリング文化の内側みたいな記事があるので、
ここを見てみてくださいと。
Inside Facebook Engineering Cultureというブログがあるそうですね。
これ気になるな。
今日はさすがに読めないんですけど、
今後もし興味がいたら読んでみようかと思います。
一応パート1、パート2に分かれていて、
5つのカテゴリーですかね。
大項目に分けられて書かれてますよということですね。
読まないけど、ざっくりその5つの項目だけいくと、
オーバービュー、いわゆる概要ですね。
次はハイアリングで採用の話。
キャリアの話。
エンジニアリングプロセスの話。
最後アドバイス、助言ですね。
ちょっとこれパート2は短いので、
パート1のほうが項目詳細のように書いてあるので、
後ほど読みます。
読んでみて、朝勝で読むかも決めようと思います。
06:02
Facebookのチームカルチャーってなかなか知らないので、
僕は読んでみたいなと思います。
本題に戻りますね。
続いていきたいと思います。
さっきのブログからの引用なんですけど、
初期のエンジニアというのは、
変更をもとに戻す方法を指示するために、
サポートファイルにリバード計画を追加していきたいと
よく話していた。
この方法はより優れたテストツールによって
年々改善もされてますよというふうに言ってます。
リスクの高い変更を出荷した場合、
後に顧客からのフィードバックを利用するというのも重要です。
リスクのある変更を出荷した後、
フォーラム、カスタムレビュー、カスタムサポートなどの
顧客フィードバックを、
フィードバックを受けられるチャンネルを用意しておきます。
またそこに誰でもアクセスできるようにしておきます。
これらのチャンネルに積極的に目を通して、
導入した変更に起因する問題が発生している顧客が
いないかどうかというのを確認しましょう。
インシデントを追跡し、またその影響を測定するというのも重要です。
過去1ヶ月間に製品が何回停止したかというのをご存知でしょうか。
過去3ヶ月間、もしくは顧客はどのような経験をしたか、
ビジネスへの影響はどうだったか、
みたいなところをしっかりメトリックス取りましょうと言ってますね。
これは自社サービスやってる会社ならやってると思いたいんですけどね。
我々みたいにクライアントワークだと、
なかなかそこまでやるとか、
一度リリースした後の運用フェーズに入って、
我々がどこまで介入させてもらえるか、
逆にクライアントがどこまで望んでるかに結構依存してしまうので、
なかなかメトリックス系っていうのが弊社はなかなかですね、
知見が弱かったりするので、
ここはビジネスモデルが違うので仕方ないんですけど。
でも自社サービスやってる会社はこういうメトリックを
しっかりと取ってるんだろうなっていうのはあると思いますし、
それをしっかりみんなが認識してるとか、
ちゃんと見てますかっていうのは割と重要かなと思いますね。
これらの質問に対して答えがもしNOとかわからないみたいなものであれば、
あなたは何も見えずに非公知ることになり、
システムの信頼性がどの程度なのかっていうのを知らないことになります。
例えば停電を追跡測定し、その影響を蓄積するために
アプローチを変更することを検討してください。
このデータはより信頼性の高いリリースを行うために、
いつリリースプロセスを調整すべきかっていうのを知るために必要です。
また、エラーバジェットを使用する場合にもこのデータが必要になりますと。
エラーバジェットを使ってリスクの高いデプロイメントを
行うことができるかどうかっていうのも決定します。
SLI、サービスレベルインディケーターとか、
SLO、サービスレベルオブジェクティブなどの測定値っていうのを用いて、
システムの可用性とかを測定したり、
システムが劣化している時間や停止している時間というのを測定したりするところから始めましょう。
この辺が導入の上限ですね。
次にエラーバジェットですね。
ユーザーにとって一時的に許容できると考えるサービスの低下量っていうのを定義します。
このエラーバジェットを超えない限り、よりリスクの高い展開、
サービスを破壊する可能性の高いような展開とか、
リスクの大きい出荷っていうのを進めても問題ないかもしれません。
09:02
ただしこのバジェットを超えたら、それ以上近道をするのはなるべくやめましょう。
基本的に近道っていうのはリスクありきなものだから、
早くてかつ安全な道がもしあるんだったら、
別に近道する必要はなく、リスクを負う必要もないので、
本当に追いたいときに追いましょう。
その代わりリスクを取ったときにリカバリできるようにしておきましょうっていうのが大事ですよね。
当たり前のことをちゃんと当たり前にやりましょうっていうことを言語化したなというふうに思います。
以上、今ので5個目の項目、Taking Programmatic Risk to Move Fasterでした。
一応ラスト6、7ってあるんですけど、
6個目はResiding on the Approach You Takeってところで、
このセクションっていうのは別のサブスクライブの記事のリンクが貼られてるんで、
そっちのほうをもちろん見てくださいっていうふうに言っています。
今回のShipping to Productionの概要の記事ですね。
1個1個多分項目に分けられていて、
もっともっと詳細にこの記事について読みたい場合は、
こっちのリンクからサブスクライブしてくださいっていうことでした。
今回の記事でも十分僕はいいなと思ってます。
今のが6個目で、7個目はOther Things to Incorporate into the Deployment Processってところですね。
このセクションについても別の記事があるんで、
そこのサブスクライブをしてくださいよっていうことでした。
最後、Takeawaysですね。
Takeawaysがちょっと長いんで、ここも読み切ったら終了かな。
そうですね。
教訓ってところですね、Takeaways。
教訓と訳すか、何と訳すか難しいですけど、
一旦教訓と今回訳します。
本番間隔への出荷方法だけでなく、ミスが起きたときにどのようにリカバリするかっていうことに
焦点を当てることが最大の収穫の一つであるっていうのは提案します。
最後にそのポイントっていうのをいくつか挙げておしまいにしたいなと思います。
一つ目ですけど、迅速な出荷と高い品質を両立させること。
その両方が可能ですよっていうふうに言ってます。
結構トレードフっていう方もいらっしゃいますけど、
ちゃんと両方を覆うことができますよっていうふうにこの方がおっしゃってますね。
一部の人が誤解しているのは、これはゼロサムチョイスだっていうことです。
早く出荷するか、それとも徹底した高品質のプロセスをゆっくり行うか。
それどころか多くのツールが高品質で迅速な出荷を支援し、
その両方を可能にすることも今はできるようになってます。
コードレビュー、CICDのシステム、リンティング、自動更新されるテスト環境、
テストテナントなどは全て高品質で迅速な出荷を支援することができますと言ってます。
自由に使えるツールとしているっていうのが二つ目ですね、次は。
この記事ではより早く、より自信を持って出荷するために使用できる多くの異なるアプローチのリストアップをしていますので、
この記事ではと言っているので、また改めてこれを読んでくれたらいいんじゃないかなと思いました。
続いて三つ目の教訓ですけど、QAっていうものですね。
12:02
QAはより迅速なリリースプロセスの構築を支援するあなたの友人ですと言ってます。
友人という表現がやっぱり海外らしくていいなと思いましたね。
チームメイトとか仲間じゃなくて友人っていうんですね。
QAエンジニアやテスターと一緒に仕事をしているエンジニアの中には、
QAが物事を遅くしていると感じている人もいるかもしれませんが、私はこの考え方に結構意義を唱えます。
QAの目標というのは高品質のソフトウェアリリースをすることです。
また迅速な出荷の妨げにならないようにすることも彼らの目標になります。
もしあなたがQAと一緒に働いているのであれば、品質を落とさずに、
より早くリリースするためにどのようにリリースプロセスを改善できるか、
彼らとしっかり協力をしてくださいというのが教訓とか提案でしたね。
続いて、レガシーコードベースに迅速な出荷を可能にするツールを導入することは困難ですよと言っています。
これは皆さんも結構経験あるじゃないですかね。
既存のシステムに新しいものを組み込むというのはめちゃめちゃハードルが高いですよね。
特にインフラレベルだったり、デプロイ周りのところがより困難になるんじゃないかと思います。
もちろん超レガシーで、主導でやっているとか、ソースコードをFFTPで上げているみたいな、
そこまで行くならばむしろ導入しやすいですけど。
さて戻ります。
ゼロから製品を立ち上げる場合に既存のコードベースに後付けするよりも、
迅速な出荷を可能にするプラクティスを設定する方法がむしろ簡単ですと。
このようなアプローチを後付けできないわけではありませんが、
そうするとよりコストがかかることになりますと。
それはそうだよねって感じです。
ラスト、バグが出ることを受け入れるということですね。
これはまあまあ、そりゃそうでしょって感じですね。
まあどっちかというと開発者はみんなこれを持っていると思っていて、
わりとお客さんだったりリーダーだったりとか、
ステーコホルダーはこれをなかなか受け入れてくれない可能性が多いなと思いますよね。
でもまあ100%完璧にバグが起きないみたいなことはありえないと思いますのでね。
人が生み出しているシステムなので。
というのは僕はあるなと思いました。
かといってシステムとか機械、AIが今後発達していって、
AIがすべて生み出したプロダクトが果たして本当にその人のためとか、
全部のケースを網羅しているかってそれは全く違う話だと思うので、
なんだかんだバグが起きることは当然だってところからスタートし、
いかに早くリカバリするとか、いかに対処するかみたいなところですね。
の決めごとをしておくほうがやっぱり健全な気はしますけどね。
はい、ちょっと余談から入りましたけど、戻ります。
いかに早くバグを修正するかに集中する。
多くのチームがいかにしてバグをゼロに近づけて本番環境に出荷するかにこだわりすぎて、
いかにして問題は素早く発見し、迅速に解決するかを考えることを
結構犠牲にしているチームが多いよっていうふうに言ってますね。
そうですね、問題は素早く発見するっていうところの環境づくりも確かに大事ですよね。
見落としがちなんですけど。
はい、というところですね。
以上、今ので教訓でした。
あとは、ファザーリーディングで他にもこんな記事があるので、
15:00
この辺見てもらってもいいんじゃないのっていうような記事のリンクがバーッと書いてあるので、
この辺見てみてくださいってことでした。
長かったですけど、実に3日に分けて読んできましたけど、
Shipping to Productionという記事を読んでいきました。
なかなか個人的には面白かったし、学び多かったなとちょっと思いますね。
はい。
というので、本記事は一旦終了して、
残り10分早い、10分はちょっと早すぎるので、
軽くJSERインフォの更新だけ見て終わりにしようかなと思います。
JSERインフォの8月25の更新ですね。
もちろん全部読んでたらキリがないので、
ざーっと読んでいって終わりにしていかなと思います。
JSERインフォ8月25ですね。
第606回ですけど、BUNですね。
BUNというフレーマークを作っている、
ちょっと知らない方ですね、というなんちゃらさんを中心に、
OVENという会社が設立され資金調達が行われるようになったよってことでした。
OVENの今後のロードマップとして、
BUNを含ませエッジサーバーのホスティングだったり、
Node.jsに向けに書かれたフレーマークのサポートの改善だったり、
半年以内にステーブル版を出すというのがやっぱり目標にしているそうですね。
本格的にビジネスにも参入していこうというぐらいの本気度らしいですね。
はい。
続いて、ユーザイングハズですね。
ハズメソッドですね。
CSSのとある記事についてリンクが貼られていて、
この記事ではCSSのハズ議事クラスについて紹介されていますと。
これ多分どこかで読んだ気がしますね、僕。
いわゆる親セレクターとしての利用方法がよく知られてますけど、
それ以外にもグリッドの利用だったり、
兄弟関係者だったり、
演算子だっけ?
との違いだったり、
シブリングコンビネーターとの組み合わせなどについても結構紹介されているので、
CSSのハズメソッドですね。
というものの紹介記事というのを見てみてくださいました。
WebKitの記事なんで、Appleの記事ですね。
はい。
続いていきましょう。
ヘッドラインですね、続いて。
ヘッドラインですけど、
まずはバージョン1.19のリリース。
1.9.0のα0のリリースです。
これ何かというと、
Reduxのツールキットですね。
Reduxツールキットの新しいリリースだそうです。
マージミューテーションの追加になったりとか、
CreateReducerのオブジェクトを渡すスタイルをデプリケートに変更したりとか、
CreateAsyncThunk.withTypesの追加になったよとか、
ちょっと細かいところのリリースですけど、
まだα0なので、
もうちょっと傍観しててもいいなと思いますが、
とりあえず先にどんな機能が出るかっていうのを知るだけでもいいので、
リリースノート見てみてくださいと。
続いて、
クラウドフレアのミニフレアってもののリリースです。
バージョン2.7.0です。
これはフェッチリクエストをモックするAPIの追加ができたりとか、
デュエラブルオブジェクトをフラッシュするAPIの追加などのみたいなのが行われたそうです。
マイナなので、
ちょこちょこの小さいものが入ったっていう感じかなと思いますね。
続いて、
さっきのですね、
冒頭にありましたオーブンっていうものの
会社が立ち上がっているということでした。
続いて、
ノードJSのバージョン18.8.0っていうのがリリースになりましたよということですね。
18:00
ユーザーランドでのスナップショットを作成・復元できる
--ビルド-スナップショットっていうオプションと、
--スナップショット-ブログっていうオプションが追加になりましたよということです。
現時点ではCJSだったりESMっていうのはサポートしていないので、
一つのファイルのみ扱えますよって言ってます。
はい、そこでした。
続いて、
サファリーテクノロジープレビュー1号にウェブキットってことですね。
サファリーの話ですね。
サファリーテクノロジープレビュー1号がリリースになったと。
エクマスクリプトプロポーザルステージ3の
シンボルズアズ・ウィークマップキーズっていうものが実装になりましたと。
あと、
コンプレッションストリームAPIの実装になったと。
いろんなものが実装になったってことですね。
最近Appleちゃんとウェブに目を向けてくれてきたっていうのが僕はすごく嬉しくてですね。
今後のサファリは割と期待したいなと思っているので、
こういう記事がちゃんと計測していただいてくれるのはありがたいなと思います。
続いて、
Dのですね、
Dのリリースバージョン1.25.0っていうのが出ましたよってことでした。
今回はDのinitコマンドの追加と、
アンステーブルな機能としてNPMコロンっていうプレフィックスで
NPMパッケージをロードできるようになるなどみたいなものが入ったそうですね。
なるほどね。
よりNPMとの親和性的なところが追加になったようです。
というところで、
あとはアーティクルだったり、
スライド動画だったり、
ソフトウェアツールライブラリーですけども、
この辺は長くなりそうなんで、
ちょっと中途半端で申し訳ないんですけど、
この辺で今日は一旦切らせていただきたいなと思います。
でもやっぱりいろいろなものが毎回ちゃんとリリースされてるっていうのを終えるのは大事だと思うので、
本当にAZさんにはいつもお世話になってますっていう感じですね。
というところです。
じゃあ今日の朝発はこの辺で以上にしたいかなと思います。
明日何を読むかちょっとまだ悩ましくてですね、
今日読んだFacebookチームのホイホイみたいなやつとか、
この辺のアーティクル系をざっと眺めて読んでいきたいかなと思ったりしていますので、
またご参加いただけたらすごくありがたいなと思います。
本日もご参加いただいた多くの方々ありがとうございました。
ちょっと環境音が本当に悪くてですね、
明日はちゃんと自宅に戻るので、
明日からまた元の配信に戻るかなと思います。
では今日火曜日ですね。
8月ももうあと2日なので、
もう今年も4分の3が終わろうとしている感じですかね。
早いですね。
4分の3じゃねえな。
11年度の4分の3か。
がもう見えてきているので、
本当1年が過ぎるのは早いですけど皆さん進捗いかがでしょうか。
ところで区切りの次になると思うのでまた頑張っていけたらなと思います。
では終了します。
お疲れ様でした。
