リリース手順書について

今日はお客様の立会いのもと、検証機にアプリをリリースしてきました。

その中で考えるべき事が５点あったので、以下に記します。

①手順書に漏れが多い

　行った手順に関する確認作業が抜けてることや、

　cpコマンドなどの漏れもあった。

　手順書とは、このように作業しますとお客様に宣言している

　ものなので、このような記載漏れはまずいと思う。

　(リリースファイルの名称ミスなどもあった)

　作成者、添削者がもっと注意する必要がある。

　今回自分も反省。

②トラブルの時の対処手段が記載されてない

　手順の中で、リリースをする前に既にリリース済のソースと、

　開発側が持っている更新前のソースのdiffをとるチェックがある。

　通常一致するはずだが、たまにそうでない場合がある。

　この場合、相違点を確認してから対処するのだが、

　その際の手順はどこにも記されていない。

　実際には対処法には経験から蓄積されたノウハウを個人が持っている。

　それをドキュメント化して共有すればいいのではないかと思った。

　今思ったんだけど、相違点があったファイルは持ち帰って検証すればよかった。

　今回で言えば、CSSのファイル・・・。

③ACCESSを利用した際の手順、チェック

　手順の中に、Microsoft Accessを利用してのデータ移行などがある。

　しかし、手順書の中では一行、・・・.mdbを実行、とあるだけである。

　実際にはクエリを多数実行しなければいけないということもあり、

　すべてのクエリをきちんと実行したかどうかの確認は

　行うべきであると思った。

　また、ACCESSの操作の手順も標準として

　どこかにあってもよいと思う。

④実行するSQL文が記載されたファイルの実行チェック

　③と重複する内容になる。

　データ移行の際に、SQL文を実際に実行する時、

　その内容をテキストファイルで保存して持ってくる。

　しかし、これも手順書の中では1行で書かれてあるだけで

　全てを実行したかのチェックは行っていない。

　別にチェックリストをつくってチェックすべきだと思った。

⑤diffコマンドの検証というか効果の測定

　リリースの前に、ソースのデグレードチェックとバックアップチェックを

　diffコマンドを利用して行っている。

　しかし、自分自身diffコマンドの詳細を理解しているかと言われると

　微妙である。

　ファイルの内容を比べて相違点を示す、ということは分かっているが、

　どのような相違点があった時にどのように表示されるかを詳しく知らない。

　これではリリース前の確認時点でもし相違点があった時対応できない。

　ので、これは自分自身の理解をもっと深めていくことが大事だなと感じた。

以上が今回のリリースで思ったことです。

最後まで読んでくれた方ありがとうございます。

よかったらご意見ください。

(書いている文章が下手で、意味が分からないと言う方もいるかもですけど)

グリーン車両初乗車

本日初めてグリーン車両を経験しました。

なんて贅沢な！と思った方、違います、

ポイントを利用して席をグレードアップさせただけです。

出張が多いと、たまにはこんないいこともあります。

グリーン車両の特徴

　・座り心地がよい

　・台が左の腕おきから出てくる

　・人が少ない(かつ静か)

　・切符のチェックがはいる

　・自席用のライトがある

こんなところかなぁ。

個人的には、グリーン車なら、寝れる！と思いました。

普遍的な寂しさ

うちの会社は、事務所が２つの階にあります。

私がいる方の階は、男性の比率が多く、

華やかさはほとんどありません。

私がいないほうの階は、男女がほぼ均等な割合でいて、

華やかな感じです。(私から見て)

来週、私がいないほうの階の若年層で飲み会があるそうです。

当然、呼ばれないおれ。

仲のいい同期は行きます。

こんな時、寂しさ感じませんか？TT

↑のせいで、仕事終わってから無性に寂しくなりました。

仕事中はこんなことは考えなかった。

おれも、仕事人間になったもんだ。

甘いけど、この部分は評価したい。