はじめに こんにちは。 今日のフィヨルドブートキャンプのLT会で話した内容についてまとめておきます。 スライドはこちらです。 speakerdeck.com もくじ はじめに もくじ フィヨルドブートキャンプで超えた壁? 1.質問が怖い 2.英語の資料が読めない 3.輪読会をする友達がいない まとめ 追記 フィヨルドブートキャンプで超えた壁? 今回のLT会のテーマは「フィヨルドブートキャンプで超えた壁」ということで、プラクティスの中で直面した困難や、乗り越え方についてシェアしようということでした。 わたしはLinuxのプラクティスではいろいろあったので、このプラクティスをテーマにして話そうかと考えていました。 ただ、ちゃんと掘り下げてみるとあまり内容に深みが出せないのと、同じLT会でLinuxで話される方が他にもいらっしゃり、内容的にかぶる可能性もありそうだったので、もう少し普遍的なテーマ
architect - システム設計 developer - システム開発 app-developer - アプリケーション開発 operator/sys-admin - 運用管理/システム管理 私が入社したころの弊社のリリースフローは、リリースブランチへの煩雑なcherry-pickの後、長いチェックリストやチケットを手動で更新した後、定期実行テストを待って次の日にデプロイ対象の変更をpushしたら、デプロイ対象のサーバー上で30分に一回実行されるcronでデプロイされるが、ランダムに失敗するので全台デプロイされるまでに数時間かかるというものでした。 あまりにも大変なのでリリースは多くても週一回しか行なわれず、変更粒度が大きくなるため毎度リスクが高いものになり、また何か起きた時もロールバックに時間がかかる厳しい状態でした。 今では、数百あるデプロイ対象の全てが当時とは異なるデプロイ方法に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く