一人現場だったので、誰も自分の暴走を止めることはできず、誰かのせいにしたいが自分の顔しか思い浮かばない
①SQLServer側の日時設定を変更できないことを知らずに、日時をDBで生成(自動入力)する
マジでアカンかった…
「現在時刻」や「今日の日付」のような値はブラウザorサーバで生成してDBに登録しましょう…DBのgetdate()のような自動入力に頼らない方が良いです。
AzureSQLの日時設定は変更できないため、SELECT時にUTCからJSTに変換する処理を漏れなく書くことになります。
なお、グローバルで使うシステムを開発するなら特に問題ありません。
②SQLServerのテーブル作成時に自動採番(AUTO INCREMENT)のIDENTITY設定をし忘れる
自動採番するカラムなのに、IDENTITYを設定し忘れると、後でALTERとかで変更ができないので、テーブルを再作成することになります。 どうして。 場合によっては漏れなくSELECT MAX(列名)+1で採番する処理を書くことになります。
https://www.ipentec.com/document/sql-server-set-column-to-identity
③AzureAppServiceにSPAのコンテンツをデプロイしても動作しなくてハマる
Nginxの設定が初期でSPAに対応していません。
/etc/nginx/sites-enabled/defaultのlocation /を書き換える必要があります。
下記に一例を載せておきます。
location / {
root /home/site/wwwroot;
index index.html index.php;
try_files $uri $uri/ /index.php?$query_string;
}
設定後、nginx -s reloadも忘れずに。
④AzureAppServiceを再起動して環境を飛ばす
これはちゃんと英語のメッセージを読んでいなかった自分がダメなんですが…
/home以外にデータを保存すると、サービス再起動したときに全て消えます。
環境変数を後から追加して、気づきました。
⑤リソースやディレクトリをよく理解せずに変な場所に環境を構築する
どのディレクトリ、どのリソースに、なにを作成するか、キチンと確認しましょう…。これも場合によってはマジで沼になります。
時代の変化に合わせて開発方法やインフラ環境も大きく変化しますよね。
新しい方法を学ばずに「旧スタイルの開発手法や知識しか持ってないけど、なんとかなるやろ」って思って、こういう細かいことを確認せずに着手すると色んなところで地獄を見ることがあります。
Azureは取り返しのつかない要素が結構多いと思います。AWSやGCPもそうかもしれないけど、本番運用が始まってから気づくと、時すでに手遅れになることもあります。
なので、自戒の意味も込めてココにメモをしておきます。