始めての現場でテスト環境に触れる時、テスト環境がどのような環境か良く分かっていないと知らず知らずの内にテスト環境を壊してしまいがちです。
このあたりのことは情報処理技術者試験の勉強をしても身に付かなかったりするので、あえて文章にしてみます。
【そもそもテスト環境とは】
その名の通りテストをするための環境のことです。
作ったプログラムをいきなり本番運用している環境に上げてしまうと、プログラムのバグでお客様に迷惑をかけてしまうので、事前にテスト環境でテストしてバグを発見・除去してから本番運用に乗せます。
なお、テスト環境の中には、バグの発見率を高めるために本番環境にできる限り構成を近づけた特別な環境が用意されることがあるのですが、そのような環境は「ステージング環境」と呼ばれることが多いです。
【テスト環境の一般的な構成】
テスト環境が一つしかないことはごく稀で、通常は複数のテスト環境が用意されています。
サーバやディレクトリ、ユーザ等を分けることで、複数のテスト環境を用意しています。
複数のテスト環境を用意する必要がある理由は、用途や案件ごとで別々の環境を用意しないと、自分のテストが他の人のテストに影響を与えてしまうからです。
用途で言うと、各々の開発者が思い思いにテストデータを投入してホワイトボックステストする環境、本番環境と同じデータを投入して業務面の確認を行う環境、日々バッチを回して運用面の確認を行う環境、といった形でテスト環境を分けます。
案件で言うと、リリース時期毎でテスト環境を分けることが多いです。例えば、5月時点の環境と6月時点の環境、といった具合です。
【開発者の心構え】
ここで開発者が心がけなければならないのは、誤ったテスト環境でテストしないようにすることです。
例えば、ホワイトボックステスト用のテストデータをバッチを回す用の環境に入れてしまったら、バッチが異常終了し騒ぎになってしまいます。
また、6月にリリースするべきプログラムを5月用の環境に入れてしまったら、5月時点の構成を再現できなくなってしまいます。
（5月リリースするプログラムに潜んでいたバグが6月リリースするプログラムの挙動で隠されてしまう、というようなことも起こり得ます）
誤ったテスト環境でテストしないためには、どのようにして環境が切り分けられているのかを知る必要がありますし、自分がどのテスト環境を使用するべきなのかを案件ごとに確認する必要があります。
環境の一覧表があったり使用するべき環境が仕様書等に書かれていたりすれば良いのですが、そのような文書が無いのであれば都度確認した方が無難です。
セキュリティルームでの共連れのリスクと防止法
IT業界だと機密情報を取り扱うことが多いので、それに関連しての記事です。
機密情報を取り扱う部屋（セキュリティルーム）では、入退室時にカードキーや暗証番号等を使用した認証が必要になります。
この認証について、リスクになるのが「共連れ」と呼ばれる行為です。
一般的には、周りに人がいる場合は、その人が入りやすくなるようにドアは開けっぱなしにするのがマナーなのですが、認証が必要なドアでこれを行ってしまうと本来権限を持たない者が機密情報に触れてしまう可能性が出てしまいます。
共連れの可能性を確認する方法としては、入室時の認証と退室時の認証の履歴を確認する方法があります。
入退室時に都度認証を行っていれば、「入室→退室→入室→退室…」と交互に履歴が残るのですが、共連れで入退室をした場合にはこの履歴が崩れるため、その崩れをもって共連れが行われたことを確認することができます。
しかしこの方法では事後的にしか確認できない上、いくら共連れしないように気を付けていてもどうしても忘れてしまうこともあります。
共連れ行為そのものを防ぐ方法としては、セキュリティゲート等のシステムを導入する方法が考えられます。
詳しくは以下のページに書かれているのですが、導入に費用と時間がかかるのがネックです。
共連れ対策 共連れを防止するには｜入退室管理のセキュア
https://secureinc.co.jp/special/tomodure/
今すぐにでもできる共連れ対策は、「認証でドアを開けたら、他の人が入る前にドアを閉める」というルールを制定し、周知徹底するという対策です。
一般的なマナーには反していますが、認証の目的を考えれば本来はこうするべきですし、セキュリティに厳しい現場の場合は本当にこのルールが運用されていることがあります。
他の人が入る前にドアを閉めるのは勇気のいる行動ですが、それをルールとして制定することで、本来必要な行動を促すことができます。
実際はシステム的にもルール的にも共連れ対策がされていない現場が多く、共連れが暗黙的に行われていることも少なくないのですが、本来はマナーに反してでも共連れは防ぐべきだというのは頭に入れておくべきだと思います。
unix／linux：ファイルを読み取り専用で開きたい時はviewコマンドで開く
unix／linuxでは、viコマンドを発行するとファイルをviエディタを開いて読み取り・書き込みが可能になります。
しかし、読み取りのみを行いたいのであれば、viコマンドではなくviewコマンドで開くべきです。
というのは、viコマンドで開くと、誤ってファイルを作成・上書きしてしまう恐れがあるからです。
ありがちなミスは、「存在していないファイルを存在していると思い込みviコマンドで開く→空の画面が出てファイルが存在していないことに気付く→viエディタから抜ける時に!wqで抜けてしまう→空ファイルが作成されてしまう」というミスです。
もし、ファイルの存在チェックを行うバッチが別に走っていたら、異常終了の原因になります。
本番環境はもちろん、開発環境でも他の開発者に迷惑をかけてしまうので、このようなミスを防ぐためにも、意図的に編集を行うわけでないのであればviewコマンドで開くべきです。
ちなみに、数行～100行程度のファイルを目検で見るだけであれば、viewコマンドの代わりにcatコマンドやmoreコマンドで見た方が手軽だったりします。
改めてDevOpsとは
「DevOps」という単語はセミナーで良く耳にしていたのですが、「ツールを導入し、開発部門と運用部門の連携を密にし、リリースの速度を上げる」というざっくりとした印象しか記憶にありませんでした。
他社のエンジニアと話したら「DevOpsはWeb画面のテストを自動化するツールの名前だよ」と言われて何が本当かわからなくなったので、改めて調べてみました。
DevOpsとは、ざっくり言うと以下のようなものらしいです。
・「開発部門(Dev)と運用部門(Ops)が連携を密にし、壁をなくす」という概念である
・サービスの迅速なリリースと安定稼働を実現するために導入するものである
・迅速な開発を行うと運用部門との連携が不可欠になるため、組織改革を行う
・組織改革する上では、文化的な移行だけでなく、ツールの導入が重要になる
・ツールとしては、テストやリリースの自動化ツール等が必要になる
私の実体験からしても、迅速なリリースと安定稼働を実現するためには、テストを終えた資材をステージング環境・本番環境へ上げる作業や資材管理を行う作業を効率化するツールが必要不可欠だと感じています。
ただ単にリリース頻度を増やすだけでは、運用担当者の作業負荷が高まってしまい、そこがボトルネックになってしまいます。
（運用担当者の長時間残業が常態化する、それに伴う運用ミスが起こる、といった状況になります）
また、DevOpsを推奨するベンダーとしても自社のツールを売り込みたいので、「DevOpsを実現するためにツールを導入しましょう！」という話になります。
というわけで、DevOps実現のためにはツールの導入が鍵を握るのですが、DevOpsの元々の目的が置き去りにされ「自動化ツール」という手段が独り歩きしているのではないか、と他社のエンジニアと話していて感じました。
（他社が独自導入しているテスト自動化ツールの名前が本当に「DevOps」という名前である可能性も否定できませんが）
サクラエディタのマクロに大量(500以上)のコマンドを記述すると一部コマンドが実行されなくなる（推測）
スペックの高いPC（詳細は後述）の場合、サクラエディタのマクロに大量(500以上)のコマンドを記述し実行した時に一部コマンドが実行されなくなる現象を確認しました。
現象が発生するPCの場合、コマンド数が600程度の時に発生したり発生しなかったりし、700を超えるとほぼ確実に発生するので、サクラエディタのスレッドの最大数が500か512あたりで実装されていて、何れかのスレッドが解放される前に次の処理を実行すると…という話なのかなと勝手に想像しています。
私の想像が的外れの可能性も高いので、どのような現象なのかは再現手順を見て各自で判断してください。
先日の「サクラエディタのマクロ（置換処理記述）をバッチから並列実行すると処理が競合する」という話もあるので、ちょっとしたフォーマット変換や修正作業なら良いのですが、移行作業でサクラエディタのマクロを使うのはあまりお勧めできないです。
多少面倒でも、javaか何かでプログラムを作った方が良いと思います。
【現象が発生するPC】
（恐らく）スペックの高いPCで発生します。
現場にはスペックの高いPCと低いPCがあり、高いPCでのみ発生しました。
（コマンド数は約800）
現場のPCのスペックを勝手に公開して良いか微妙なので、スペックは伏せます。
参考情報として、以下のスペックを持つ私の自宅のPCでは5回中1回発生しました。
（1003コマンドの場合）
・OS
Windows 8.1
・プロセッサ
Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz 2.40GHz
・実装メモリ
8.00GB
【現象の再現手順】
１．大量（1000個）の置換処理をマクロに記述する。
最後に、再描画、上書き保存、閉じるの処理を記述する。
例
S_ReplaceAll('hoge1000', 'fuga1000', 62); // すべて置換
S_ReplaceAll('hoge999', 'fuga999', 62); // すべて置換
S_ReplaceAll('hoge998', 'fuga998', 62); // すべて置換
：
：
：
S_ReplaceAll('hoge3', 'fuga3', 62); // すべて置換
S_ReplaceAll('hoge2', 'fuga2', 62); // すべて置換
S_ReplaceAll('hoge1', 'fuga1', 62); // すべて置換
S_ReDraw(0); // 再描画
FileSave( ); // 上書き保存
WinClose( ); // 閉じる
２．１で作成したマクロを以下の記事の要領でバッチから起動可能にする。
サクラエディタのマクロをバッチファイルで複数ファイルに対して実行
https://akira2kun.hatenablog.com/entry/2018/09/16/103138
３．処理対象のファイルを用意する
上記記事の例で言うと、
workフォルダ内に任意のファイルを格納する。
４．２で作成したバッチを起動する
５．サクラエディタで開かれた３のファイルが閉じられないことを確認する。
【現象の回避方法】
１つのマクロの中のコマンド数が多くならないように、マクロを分割する。
少なくとも、コマンド数が100程度であれば、
「WinClose( );」により必ず自動的にファイルは閉じられる。
（10000回以上試したが全て自動的に閉じられた）
サクラエディタのマクロ（置換処理記述）をバッチから並列実行すると処理が競合する
サクラエディタの Ver2.2.0.1 にて表題の挙動を確認したので、記録に残しておきます。
【再現手順】
１．大量（確認時は1000個）の置換処理をマクロに記載する。
例
S_ReplaceAll('hoge1000', 'fuga1000', 62); // すべて置換
S_ReplaceAll('hoge999', 'fuga999', 62); // すべて置換
S_ReplaceAll('hoge998', 'fuga998', 62); // すべて置換
：
：
：
S_ReplaceAll('hoge3', 'fuga3', 62); // すべて置換
S_ReplaceAll('hoge2', 'fuga2', 62); // すべて置換
S_ReplaceAll('hoge1', 'fuga1', 62); // すべて置換
S_ReDraw(0); // 再描画
FileSave( ); // 上書き保存
WinClose( ); // 閉じる
２．１で作成したマクロを以下の記事の要領でバッチから起動可能にする。
サクラエディタのマクロをバッチファイルで複数ファイルに対して実行
https://akira2kun.hatenablog.com/entry/2018/09/16/103138
３．処理対象のファイルを用意する
上記記事の例で言うと、
workフォルダ内に置換対象の文字を含むファイルを格納する。
例
hoge1000
hoge999
hoge998
：
：
：
hoge3
hoge2
hoge1
４．２～３のフォルダ構成を複数作成する。
上記記事の例で言うと、tmpフォルダをコピーしtmp2フォルダを作成する。
（バッチファイルの１行目・５行目の記述もフォルダ名に合わせて変更する）
５．４の各々のフォルダで同時にバッチファイルを起動させる。
６．workフォルダ内のファイルを開き、競合の発生を確認する。
例
fuga1000
fuga999
fuga998
：
：
：
fuga3
fuga2
fuga1
とならず、「hoge951」が「fuga920」になる等不正な結果になる。
