SmartReleaseを使うためにCPIを選ぶ

CPIの特筆すべき機能として、 SmartRelease （スマートリリース）があります。Webサイトを効率的に安定して運営するためには非常に便利な機能です。

誰でも一度は「テスト環境では動いたのに公開環境（本番環境）で動かない！」と、焦った経験があるのではないでしょうか。SmartReleaseはそのような問題を解決します。

何が問題なのでしょう？多数のファイル転送の煩雑さであったり、パス修正が発生したり、PHPのバージョンが違ったり、ライブラリがなかったり、・・・と、色々な原因が絡み合うことで、トラブルが生じ無駄な修正時間を必要とします。

スマートリリースでは、テスト環境の内容を ワンクリック で公開環境にそのまま反映させることが可能です。テスト環境と公開環境が同じサーバーにあるため、動作環境の違いによる不具合はまず起こりません。

スマートリリース機能のために、コントロールパネルも 「公開サイト用設定」 と 「テストサイト用設定」 で分かれています。機能的にはほぼ同じものですが、FTPアカウントやCronなどは環境毎の設定となります。

※ テスト環境＝テストサイト、公開環境＝公開サイト、としてお読みください。

スマートリリースとは？

できることは非常に強力ですが、操作方法は非常にシンプルです。主な機能は 「リリース」「ファイル転送」「バックアップ」 、この3つです。それぞれを簡単に説明します。

「リリース」 機能はテスト環境を公開環境にコピーします。 「ファイル転送」 機能は「リリース」の反対の動作となり、公開環境をテスト環境にコピーします。リリース（公開）は直感的な言葉ですが、ファイル転送は少し分かりにくいですね。

テスト環境でコンテンツの表示確認（動作確認）を行い、問題がなければリリースを実行します。わざわざFTPでファイルを送る必要もなく、（データ量にも依りますが）瞬時にテストサイトの内容が公開サイトに反映されます。

「バックアップ」 機能は、テスト環境、公開環境、さらに 「データベース」 のデータを自動的にバックアップします。バックアップデータは 別サーバー に保存されるため安心です。

テストサイトには「smartrelease.jp」のサブドメインが割り当てられます。

• テストサイトのURL
  • http://UserID.smartrelease.jp/
• 公開サイトのURL
  • http://独自ドメイン/ または http://IPアドレス/

テストサイトのアクセス制限

最初にスマートリリースにアクセスすると、このようなダイアログが表示されます。

スマートリリースを使い始める第一歩は「アクセス制限の設定」です。テストサイトを外部に公開する必要はないため、IPアドレスによる制限を行います。複数のIPアドレスを登録することができます。IPアドレスによるアクセス制限はテストサイトのみ適用されます。

クライアント（顧客）にサイトデザイン等を確認してもらうときには、そのクライアントのIPアドレスを登録しておく必要があります。当然ですが、IPアドレスを登録しなければ、アクセス制限は無効となります。

IPアドレスによる制限が困難であれば、BASIC認証を利用することもできます。BASIC認証は「ウェブコントロールパネル」で設定できます。

リリースとファイル転送

SmartReleaseでは「リリース」と「ファイル転送」のコピー方向が異なる機能があります。リリースはテストサイトから公開サイトへ、ファイル転送は公開サイトからテストサイトへコピーします。どちらの機能もコピー方向が違うだけなので、「リリース」機能のみ説明します。

基本的な操作は、「すべてリリース（転送）」です。後述する除外リストに登録されているファイルやフォルダを除き、全てのデータをコピーします。コピー先にのみ存在するデータは全て削除されます。

ファイルやフォルダを選択してリリース

もう一つの方法は、「ファイルを選択してリリース（転送）」です。その名の通り、選択したファイルやフォルダのみコピーします。フォルダを選択した場合、そのフォルダ以下のデータは全て上書きされ、コピー先にのみ存在するファイルやフォルダは削除されます。

除外リスト

リリース（ファイル転送）から除外するフォルダとファイルを登録することができます。例えば、データベースのアクセス先など、公開サイトとテストサイトで異なる設定ファイルをコピーしないようにすることができます。

SmartReleaseにおけるデータベースの扱い

勘違いしそうですが、データベースは環境毎に存在するわけではありません。公開サイトとテストサイトのディレクトリは完全に別領域ですが、データベースは共有です。つまり、リリースやファイル転送を行っても、データベースには何も影響はありません。

データベースは同じものを共有するため、リリース後にテスト環境でデーベースを修正すれば、当然公開サイトにも影響が出ます。この問題を避けるためには、テストサイト用のDBと公開サイト用のDBを分けるといった工夫が必要となります。

バックアップ機能

スマートリリースには標準機能とは思えないほどの、高機能なバックアップ機能が備わっています。Web領域のデータは30世代まで、データベースのデータは10世代まで保存されます。「テストサイト」「公開サイト」の両方がバックアップ対象となります。

手動バックアップを行わなければ、Web領域なら30日間（30世代分）、データベースなら10日間（10世代分）のデータが保存されることになります。

バックアップ対象|公開環境|テスト環境|データベース 保管世代|30世代|30世代|10世代

バックアップ機能のないレンタルサーバーを利用していれば、頻繁にバックアップをとることは困難です。ローカル（ユーザーのパソコン）にバックアップをとろうにも、データ容量によっては非常に時間が掛かり、転送量制限にも影響があります。スマートリリースであれば、定期的にZipファイルをダウンロードするだけで済みます。

管理者だけが投稿するサイトであれば、サーバーのデータが消えても、開発環境にあるデータで復旧可能でしょう。しかし、誰でも投稿可能なユーザー参加型のサイトであれば、外部からのデータが蓄積されるためバックアップは必須となります。そう考えるとスマートリリースのバックアップ機能は非常に便利です。

バックアップデータからの リストア も可能です。毎日バックアップされるので、過去（最大）30日間であれば、任意の日付の状態に戻すことができます。ただし、データベースを使っている場合は10日間となります。

バックアップのタイミングは以下の通りです。

毎日深夜帯|毎日深夜にバックアップを実行 リリース時|すべてリリース、ファイルを選択してリリース時に公開サイトのバックアップを実行 ファイル転送時|すべて転送、ファイルを選択して転送時にテストサイトのバックアップを実行 リストア処理時|バックアップ一覧よりリストアを行うと、現行のカレントディレクトリのバックアップを実行 手動|いつでも実行可能

世代上限を超えると、バックアップの度に古いデータから削除されます。もし削除されたくないバックアップがあれば 「ロック」 することも可能です。

バックアップデータのダウンロード

バックアップデータは個別にダウンロードすることも可能です。ダウンロードしたいバックアップ（日付）を選択すると、そのデータがZIPファイルにアーカイブされます。

スマートリリースの制限

下記の項目に一つでも該当する場合、 スマートリリースは機能しません。

• ファイルの総数が70,001ファイル以上の場合
• ファイルの総容量が10GB以上の場合
• ディレクトリ構造が41階層以上の場合

「/log」と「/ smartrelease except」は、これら条件の対象外です。「 smartrelease except」はスマートリリースの対象外となるため、バックアップ等の対象に含めたくないデータを保存しておけます。

データベースのバックアップは MySQLのみ です。PostgreSQLは対象外です。

メリットばかりではない

追記メモ

URLの問題については対応方法があります。こちらの記事 を参考にしてください。

スマートリリースは確かに便利な機能ですが、いくつか注意する点があります。Webサイトの作りにも依りますが、ドメイン（URL）依存の仕様や機能があると問題が生じます。また、データベースが共通であることも考慮する必要があります。

• テストサイトのURL
  • http://UserID.smartrelease.jp/
• 公開サイトのURL
  • http://独自ドメイン/

テストサイトと公開サイトとの違いはドメイン名となります。プログラム動作の条件にURL（ドメイン）が含まれる場合、リリース前に修正する必要があります。

除外リスト機能を利用して、テストサイトと公開サイトで異なる設定が記述されたファイル（iniファイルのような）をコピーしないなど、スマートリリースを効果的に利用するには少し工夫が必要です。

最もわかりやすい例がWordPressです。WordPressはデータベース内にサイトのURL情報を格納しています。

単純にリリースしただけでは、公開サイトのURLと異なるため、データベース内のURLを書き換える必要があります。もし、この手間が面倒であれば公開サイトとテストサイトでデータベースを分ける必要があります。もしデータベースを共有するなら、何かしら手段（スクリプト等）でリリース前に修正する仕組みが必要となります。

まぁWordPressであれば、ドメイン（URL）変更用のスクリプトも公開されているので、あまり問題にはならないかもしれませんね。

SmartReleaseにおけるデータベースの問題点を挙げてみましょう

• テストサイトと公開サイトで共有する
  • 上述のWordPressのような問題が生じます。
  • テスト環境でデータベースを編集すると、公開サイトにも影響が出ます。
• テストサイトと公開サイトで分ける
  • データ更新を運営者のみが行うなら問題は生じません。ただし、リリース時にデータベースを更新する必要があります。
  • 誰でも投稿可能なユーザ参加型サイトの場合、リリースの度にテストサイトと公開サイトのデータをマージする必要があります。

上手く利用すれば効率的なサイト運営が可能ですが、下手に利用するとトラブルの原因にもなります。