簡単な自己紹介
18日にポツンと空いていたので、枯れ木も山のなんとやら..で書かせて頂きます。
エンジニアとしてもうすぐ7年目になります。専門はバックエンド(メイン：Java/C#)です。
しかし、少人数開発かつ安定していない現場が多かったため、足りないロールは巻き取って仕事をすることが多く、AWSの構築を一部やったり、アプリ(iOS/Android/ReactNative)の面倒を見たこともあります。
最近１年で一番やって楽しかった仕事は、bitriseでリリースやstgアプリ環境構築したこと。
一番嫌だった仕事は、超レガシーなReactNativeアプリをAndroid64bit対応でバージョンアップしたこと。(なお私はバックエンド担当...)
もう完全にバックエンド関係ないですね
やらかした案件概要
エンジニアとして２年目の秋になります。
とある、Webサイト構築屋さんにエンジニアとして出向していた時になります。
この現場は良い言い方をすると、とても個人に裁量があって自由な会社。
基本的にミーティングは最初に説明するだけ。あとは納期だけ示されて、それまでに作っておけばOK。
コードレビューはないですし、テストも構築者が各自行うこと。テスト内容とか顧客からの要望がなければ作る必要はなし。
時期が来たら営業から本番環境の情報が渡されて、エンジニアが決められた日取りに一人で作業してリリースする。
もし、何か分からなかったら、その辺の人捕まえて聞いてね♪
そんな現場でWordPress(WP)新規Web案件2件を短納期で構築した後に、MovableType(MT)案件にアサイン。
案件のざっくりした内容は・・・
- 既存Webサイトのリプレース案件
- 構築サイトは小さく、納期：3週間。
- 元のサイトもMTで構築されていて、引き続きMTで構築。
- お知らせ・ブログ記事は引き継いで欲しい。
やらかした流れ
私「いやーMTとか経験ないんですけど、3週間いけるもんなんですかね？」
営業「大丈夫！大丈夫！ WordPressみたいなものだから！」
とりあえずサクッと先輩エンジニアに聞いて構築開始
私「MTって現環境引き継いだまま、ローカル環境作るにはどうするんですかねー？」
先輩エンジニア「ローカル環境を作って、本番DBをダンプしてローカル環境用に一部直してリストアすればいいよー」
ということで、下記の手順で実施。
- ローカル開発環境を作る
- 本番環境のDBをダンプする
- ローカル用に手直し(本番環境のURL/フルパスをローカル用に置換)
- ローカル環境のDBにダンプした内容をリストアする
ハマって実装ギリギリ
MTはかなりWPとかなり違うもので、全く思った通りにいかなったけど、色々考え方違うことを実感しつつ、
ドキュメントもそこそこあったので、駆使して実装することで確実に完了に向かっていった。
・・・しかし。実装終盤に全く原因が分からない事象に出会ってしまう。
あるコンテンツ内に関連する別コンテンツを入れ子構造(1対多)にしたテンプレートを実装した時のこと。
子コンテンツの内容を変更したので、全てのページの該当コンテンツが変わることを期待したのだが、
なぜか子コンテンツの内容が全く変わらない・・・。
いくらなんでも、こんな分かりやすいバグがあるとは思えない。
何かおかしいことした？...が。いくら確認しても実装ミスした感じはない。
結論から言えば、MTはコンテンツ保存時にサイト構築アクションが実行されて、影響あるページを静的HTMLとして
出力する仕組みになっているのだが、実装方法がまずかったか、構築アクションが適用されなかったようだ。
（もはや実装内容は覚えていないけど、おそらく自分の知識不足が原因だと思う）
結果として、期限ギリギリに。
リリース日
厄介なことは多々あったけど、なんとかリリース日には間に合った！！
リリース手順等の確認とか全くできてないけど、基本的に開発開始と逆手順をすれば問題ないはず。
下記がリリース手順（基本的に、開発開始の方法と逆変換）
- ローカル環境のDBをダンプ
- 本番用に手直し(ローカル環境のURL/フルパスを本番用に置換)
- 本番環境にログインして、本番DBに適用する
- 本番環境MTの接続先を新規DB側に向ける
- 問題が発生したら、DBの向き先を元に戻す
この手順でリリース後動作確認。問題なく動いてるようなので、顧客に確認してもらう。
（２−３時間後、OKもらう）
後日
営業から連絡を受ける。
「あのー・・。最近から３週前にかけて、ブログ記事がなくなったらしいんですけど、何か知りませんか？」
！？
何が起こったか
ローカル開発環境を作ってから、実装完了までの間。顧客側でもブログやお知らせを配信しており、
開発環境にその内容を取り込まないまま、ローカル開発データを本番環境に上げた。
この事象を発生させないために何をすべきだったか
[絶対に必要だったこと]
先輩エンジニアに状況をしっかり説明してレビューをしてもらうこと。
少なくとも過去にやったことがないリリース(MTもそうだけど、データを継承したリプレース自体初めて)は必ず見てもらうこと。
[絶対に必要だったこと２]
顧客に対して、現状開発中のため、コンテンツの追加・編集・削除した場合は、その情報を共有してもらいリリースまでに取り込むようスケジュールすること。
[技術的には]
今回の構築では、コンテンツデータおよびテンプレートデータを構築してました。
そして、MTはテンプレートとコンテンツがDBに同梱されているため、基本的にはDBを適用するしかリリースできないと勝手に思っていました。
後日、先輩エンジニアから聞いたところによると、デザインのインポート・エクスポート機能があり、デザインだけ既存DBに取り込むこともできたそうです。。。（最初に教えてくれョ・・・
）
もちろん、コンテンツデータは開発側と顧客側の双方で追加しているので、その部分はマージする必要がありますが、
既存DBにこちらで作成した新規データを入稿すればいいだけなので、少なくとも顧客側のデータを消すなんていう恐れはなかったわけです・・・。
幸運にも大事にならずに済みました...
既存DBを残していたため、それを切り替えることによって、すぐに復旧はできました。
既存DBから、３週間分のデータ差分を営業の人に顧客とコミュニケーションを取って抽出してもらい、
新規DBに移植してもらったことにより、データの消失は防げました。（なので、、タイトル詐欺にはなります
）
自分は、他社の人間ということもあり、自分が直接謝ることはありませんでしたが、
謝ってくれた営業さん。今回の件で、顧客からの追加要望のjsのIE7対応引き受けて対応してくれたデザイナーさん。
この時は、本当ありがとうございました。。。
最後に
「今回もなんとかできる！」そんな、慢心が招いた事態を今回題材にさせて頂きました。
今回、このような機会に改めて、回想してみました。
リリース日、この事態を自分で防ぐ方法はあっただろうか？
...おそらく無理だっただろう。あの時は、技術力もなく、間違った手順を間違いと気付けなかっただろう。
そうだとすれば。グループとしてどう防げばよかったのだろう？
その時、自分が先輩エンジニアの立場だったら、どういったことができただろうか？
こういった事態が発生する前に、若いエンジニアに伝えるべきはなんだったのだろう？
---気付けば中堅エンジニアとして、年数の浅いエンジニアとも仕事をすることが増えました。
今では自分の経験を踏まえ、理解できていないことを気づかせる環境づくりが一番大事なことだと思っています。
これにより、自分と同じような経験をするエンジニアが減るのであれば、これに勝る幸せはありません。
最後まで、おつきあい頂きありがとうございました。
最後に今回このような素敵なAdventカレンダーを開催して頂いた主催者様、
そして、拙い文章ですが、読んで頂いた皆様、本当にありがとうございました。