@idler

Are you sure you want to delete the question?

If your question is resolved, you may close it.

Leaving a resolved question undeleted may help others!

We hope you find it useful!

静的サイトの保守についてアドバイスが欲しい

解決したいこと

Node.jsなどの開発環境で生成した静的サイトの修正時に関して、

  1. 過去のすべてのページ修正は、開発環境を復元して対応していますか?
  2. それとも、一定期間(例:1年間)以内のサイトは開発環境で修正し、それ以前の古いサイトは直接サーバー上の静的ファイルを修正していますか?

保守運用の管理方法がバラバラで困っているため、皆さまの運用方法をお聞かせください。
なお、保守費用は設定せず、修正ごとに作業単位で費用をいただく形態の環境です。


経緯

定期的に新規依頼を受けている案件があり、今回全体の修正依頼が入り、過去に制作した約100ページを修正対応しました。
しかし、これまで保守方法や運用方法が統一されていなかったため、数年前のサイトでは開発環境が残っていなかったり、ビルド成果物も各担当者によって異なっていました。
例えば、webpackでバンドルされたものやプレーンな静的ファイルなどが混在しており、調整が単純ではありませんでした。
このため対応に苦労したことから、今回保守運用の方法を統一したいと考えています。
そこで、皆さまの運用方法をお伺いしたく投稿させていただきました。


現在考えていること

上記の②の方法を検討しています。
一定期間(例:1年)以内、または開発環境が残っている間は開発環境から修正し、
一定期間を過ぎたものは基本的にサーバー上のファイルを直接修正して対応しようと考えています。

その際、継続的な保守も考慮してファイルの圧縮は行わず、共通部分はできるだけ共通ファイルとして切り出し、呼び出し利用する形で運用していこうかと考えています

0 likes

1Answer

動的か、静的かに関わらず、原則全てのリソースは開発環境を構築の上、改修を行うことが望ましいです。
ですので、①を推奨します。

私自身も、過去に本番環境しか存在しないプロジェクトを経験しましたが、その際は本番環境の全リソースを開発環境(貸与されたノートPC)にコピーし、ハードコーディングされていた環境固有の定数値も全て手直しして、開発用の環境をゼロから立ち上げました。

本番環境のリソースを直接修正した場合の事故リスクに対し、どの程度許容できるか、例えば、終日サーバーが500エラーを返す状態に陥っても問題としないのであれば、本番サーバー上のファイルを直接直しても良いかもしれません。

ただし、やはりあるべき姿は、開発環境で動作を確認し、ステージング環境へデプロイして、リリースのプロセスに問題ないことを検証し、本番環境へリリース、の流れを遵守することです。

リソースの物量や、今後の共通化も視野に入れていらっしゃることを鑑みると、先行投資として開発環境を整備した方が、後の共通化作業も楽になるだろうと考えます。

もしご参考になりましたら幸いです。

1Like

Your answer might help someone💌