目的

1. アーキテクチャ方針

多くのシステム管理チームは自社のエンタープライズ アプリケーションについて、ステージング環境やフェイルオーバー セットアップなどのアーキテクチャを確立しています。このドキュメントの推奨事項は、そのような組織全体の方針の変更や置換を意図するものではありません。アトラシアン製品をステージング環境で取り扱う際に考慮すべき点を明らかにするものです。 

定義

このドキュメントの説明では、次のように用語を定義します。

• Production: your live instance, expecting minimal downtime and well-tested changes.
• ステージング: 本番の前段階の環境。システム管理チームがロールアウト前に正確な手順を確立できる。
• 開発: 全員が利用できる自由な環境。ユーザーは最先端の変更やリスクを伴う変更を試すことができる。 

推奨事項

アトラシアン製品がクリティカルなシステムである場合、開発、ステージング、本番の 3 階層のアーキテクチャを推奨します。

• ステージング環境の主な目的は、本番段階に進む前の変更やアップグレードをシステム管理者がテストすることです。
• 開発環境は、さまざまな事業単位が本番環境へのロールアウトを依頼する前に変更を独自でテストする場所です。

2. ガバナンス方針

In addition to architecture, we also recommend establishing a governance strategy for changes. This could include:

• プラグイン インストール リクエストのデプロイとテストのための戦略作成。ある環境で非常に有用なプラグインが大規模なクリティカル システムでは適切でないことがあることに注意してください。

• 開発環境のリフレッシュ タイムラインの公開。

3. How to refresh a Staging Server

ここでは、既存のステージング インストールを保有しているものと仮定しています。お持ちでない場合は、これらの手順を利用してステージング環境をセットアップできます。 

3.1 以降の代替策のいずれかを利用して本番環境の完全なバックアップを作成

1. Bitbucket Server Backup Client (not supported by Bitbucket Data Center)
2. Bitbucket DIY Backup

3.2 本番環境のバックアップ全体をステージング環境にコピー 

1. ステージング サーバーをシャットダウンします。
2. バックアップに利用した方法に基づき、バックアップをステージング環境に復元します。 
   1. Backup Client から新しく作成した DB を利用するように復元
   2. DIY Backup の復元

3. システム環境変数 BITBUCKET_HOME が適切に設定されていることを確認します。詳細については「Bitbucket Server のホーム ディレクトリの設定」をご確認ください。
   
   

3.3 ステージング環境で固有の構成を実施

<Connector port="7990"
     protocol="HTTP/1.1"
     connectionTimeout="20000"
     useBodyEncodingForURI="true"
     redirectPort="443"
     compression="on"
     compressableMimeType="text/html,text/xml,text/plain,text/css,application/json,application/javascript,application/x-javascript"
     secure="true"
     scheme="https"
     proxyName="mycompany.com" 
     proxyPort="443" />

3.4 ステージング環境の分離

データがコピーされて Bitbucket Server の構成が更新されたり、ステージング環境を本番 (およびほかの) 環境から完全に分離することが推奨されます。これは、ステージング インスタンスが他の連携システムに接続したりそれらとやり取りしたするのを防ぐためです。このような例には、アプリケーション リンク経由で接続されたアプリケーションや Bitbucket Server のスマート ミラーが考えられます。 

これを行うもっとも簡単な方法は、/etc/hosts (Linux) または C:\Windows\System32\drivers\etc\hosts (Windows) ファイルを編集し、すべての関連するホスト名が転送対象外の IP アドレス (例: 0.0.0.0) を指すようにすることです。例:

0.0.0.0 jira.company.com crowd.company.com mirror.us.company.com

Instead of modifying the host's file, you can also block traffic via firewall rules if you prefer.

3.5 Remove Smart Mirror settings

If you are using Smart Mirrors or Mirror Farms with your production instance, you need to remove their configuration from the staging instance before starting it, because otherwise, your staging environment may attempt to synchronize with the mirrors.

Bitbucket 8.0 以降では、初回の起動時にのみ bitbucket.properties に次のプロパティを追加することでこれを行えます。起動後にプロパティを削除またはコメント アウトします。 

# Deletes mirror configuration on startup - Should only be run once on staging only.
plugin.mirroring.delete.on.startup=true

バージョン 7.21 以前では次のクエリを利用してデータベースから構成を削除できます。

DELETE FROM plugin_setting WHERE key_name LIKE 'acnct.bitbucket.mirror.%';
DELETE FROM plugin_setting WHERE key_name = 'ac.addon.list' AND key_value LIKE '%mirror%';
DELETE FROM "AO_8E6075_MIRRORING_REQUEST";
DELETE FROM "AO_8E6075_MIRROR_SERVER";

3.6 Disable webhooks

The existing webhooks may try to contact production resources when triggered by Git activity. In order to avoid this from happening, you can disable the webhooks via the database:

1. View the webhooks:
   

   -- The select query below is an example for a specific webhook name. Remove the where clause to retrieve all webhooks.
   select a.*, r.name from "AO_A0B856_WEBHOOK" a JOIN repository r on cast(a."SCOPE_ID" as integer)=r.id where a."NAME" = "Test";

2. Run the update query to disable webhooks:

   These queries must be run on the staging copy of your Bitbucket Server database. Only execute if the instance is down. They must never be run on your production database unless explicitly instructed to do so by Atlassian Support.

   -- The update query below is an example for a specific webhook name. Remove the where clause to update all webhooks.
   update "AO_A0B856_WEBHOOK" where "NAME" = "Test"
   set "ACTIVE" = false;

3.7 Remove OAuth ConsumerService record from plugin_setting table

Remove com.atlassian.oauth.consumer.ConsumerService:host.__HOST_SERVICE__   record from plugin_setting table. This record contains oauth private key and Bitbucket Base URL which is referenced while creating application links with other Atlassian Products.
Having this record in the Bitbucket staging instance can lead to the display of Bitbucket production Base URL in integrated applications (such Jira, Jira Cloud, Bamboo etc.,) instead of Bitbucket staging URL.

delete from plugin_setting where key_name like '%com.atlassian.oauth.consumer.ConsumerService:host.__HOST_SERVICE__%';

Note that Bitbucket automatically creates the record (if not present) with the current instance setup during the process of creating application links.

3.8 ステージング サーバーの再起動

これで、サーバーを再起動する準備が整いました。再起動したら、前述の手順を安全に実行したことを確認するために次の事項を確認してください。

1. データベースが本番環境を参照していないことを確認します。これを確認するには、[管理] > [サポート ツール] > [データベース情報] に移動してシステム情報を確認します。[接続 URL] が適切な場所を指しているのを確認します。
2. Ensure emails are disabled or configured for the dev server. (Administration > Mail server)

3.9 起動後の修正

1. If you can't log in. It could be that the External Directory that was configured in production is not available from the restored instance for some reason. You can get around this by using the Lockout recovery process procedure, removing the external directory, creating an admin account, log out, and start using the new admin account to perform your instance configuration.
2. サイトのベース URL の更新。「Bitbucket のベース URL の指定」を参照してサイトの URL をステージングの URL に変更します。
   
3. Update License to a Developer License.  See our licensing FAQ to generate a license for the staging server. Refer to Update your license key to apply it.

4. Reconfigure app links. If you are connecting to other servers via app links, you'll need to change the server ID for those instances. 

   If you leave app links in place, it's possible to have your production instance point back to the staging server, if a link is generated.

5. CI ツールをご利用の場合はビルドをトリガーする hook が構成されていないことを確認します。Bamboo を利用している場合、アプリケーション リンクを無効化したタイミングで対応できます。Jenkins 等を利用している場合はこれらの hook を手動で無効化または削除する必要があります。 
6. リポジトリやビルド システムに影響するプラグインについては、本番システムに影響を与えるかどうかを確認する必要があります。たとえば Mirror プラグインを利用している場合、ステージング環境へのプッシュが外部の本番システムにミラーされないように接続を編集する必要があります。