RedmineのVerUp手順はSVNチェックアウトが最善

RedmineのVerUp手順はSVNチェックアウトが最善である記事があったのでメモ。

【参考】
Redmine 3.4 にリポジトリ(SVN)からアップデートしてみた - netazone.net

Redmineのバージョンアップに追従していくための一工夫 from Go Maeda

（一部引用開始）
【前提条件】
稼働中のRedmine をSVNチェックアウトで構築していること

【方針】
SVN経由で更新すると、当然そのディレクトリが更新されるので、事前にコピーをとっておく
Redmine　ディレクトリをコピーすることでテーマやDBの設定ファイルを引き継ぎ
プラグインは一旦全部外す(サブディレクトリに退避)

【感想】
リポジトリ(SVN)からソースをチェックアウトでのバージョンアップをやってみて

すごく簡単。設定ファイルのコピー漏れなどつまらない失敗も起きない

自分でパッチ当てたところもキャッチできる
（手動でパッチを当てたファイルを失念しており、conflict が発生）
（一部引用終了）

tar.gzではなく、SVNチェックアウトでVerUpする利点は、いくつかある。

一つ目は、以前の設定ファイルの情報などが引き継がれること。
つまり、設定ファイルの移行作業は必要ない。

二つ目は、手動でパッチを当てたファイルは、svn updateでconflictが起きるので、事前に危険なファイルやマージを検知できる。
conflictが起きたソース一覧を事前に洗い出しておけば、こういうマージ作業でRedmineが正常動作しなくなるリスクを減らせるはず。

三つ目は、VerUp作業を自動化できる可能性があること。
稼働中のRedmineソースとDBを毎日バックアップしていれば、その環境を使って、svn updateとDBマイグレーションなどのVerUpコマンドをシェルにしてしまえば、VerUp作業そのものを自動化できる。
つまり、何度でもVerUp後の検証環境を作れるし、何度でも検証作業を試せる。

マイナーバージョンアップ（たとえば、3.3.x→3.3.4）であれば、DBマイグレーションもないので、svn updateによるファイル更新だけでVerUp作業が完了できる。
つまり、マイナーバージョンアップなら、VerUp作業を自動化した時に失敗するリスクも小さい。

さらに、DockerやAnsibleなどでサーバー環境そのもので自動構築したりバックアップしているならば、VerUp手順だけでなくサーバー構築手順も合わせて自動化してしまえばいい。

そうすれば、ブルーグリーン・デプロイのように、古いバージョンと新しいバージョンの環境を切り替えるようにしたり、イミュータブル・デプロイのように、古いバージョンの環境は捨てて、新しいバージョンの環境を使うこともできるだろう。

継続的デプロイ＆ダウンタイムなしのデプロイのために - Qiita

DevOps時代の開発者のための構成管理入門（終）：継続的デリバリ／デプロイを実現する手法・ツールまとめ (1/2) - ＠IT

ブルーグリーン・デプロイやイミュータブル・デプロイの導入によって、OSやRubyのようなミドルウェアのバージョン依存で本番システムが動かなくなって、元に戻せなくなるリスクが格段に減らせる。

いわゆる継続的デリバリーの概念をRedmineのVerUp作業にも適用できるわけだ。