How to establish staging server environments for Bitbucket Server

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問

目的


This document describes best practices for an enterprise environment setup for Bitbucket Server:

  • 変更管理に関する最適手法のアドバイス
  • 開発 / ステージング / プロダクション アーキテクチャのアドバイス
  • 非プロダクション サーバーのデプロイ方法に関する技術手順

仮定 :

  • このドキュメントでは、管理者は変更を定型化したいものと仮定しています。したがって、UI ベースの変更や、ファイルシステムの場所の指定に便利なデータベース設定ツールなどの個別ツールに関する説明は省きます。

このページの内容:

tip/resting Created with Sketch.

注意:

  • The procedures described in this document will work with Bitbucket Server version 4.0 and later.
  • ステージング サーバーを起動する前に、このドキュメントを一読してください。プロダクション インスタンスへの接続に関連するリスクが存在するので注意が必要です。このドキュメントでそれらの注意点を指摘します。

1. アーキテクチャ方針

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

定義

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

  • プロダクション : 実稼働インスタンス。最小限のダウンタイムと十分なテスト済みの変更を要求。
  • ステージング : プロダクションの前段階の環境。システム管理チームは運用開始前に正確な手順を確立できる。
  • 開発 : 自由な環境。ユーザーは最先端の変更やリスクを伴う変更を試すことができる。 
アドバイス

アトラシアン製品が基幹系システムである場合、開発、ステージング、プロダクションの3段階アーキテクチャを推奨します。

  • ステージング環境は、システム管理者がプロダクション段階へ進む前に変更やアップグレードをテストすることが主要目的です。
  • 開発環境は、様々な事業単位が運用リクエストに先立って独自の変更をテストする場です。

2. ガバナンス方針

アーキテクチャに加えて、次のような変更管理方針の確立を推奨します :

  • プラグイン インストール リクエストのデプロイとテスト向けの方針作成。ある環境で非常に有用なプラグインが大規模基幹系システムでは適切でないことがあることに注意してください。
  • Publish a timeline for refreshing the development environment.

3. ステージング サーバーのリフレッシュ方法

ここでは、既存のステージング インストールを保有しているものと仮定しています。まだ持っていない場合は、早速この指示に従ってステージング環境を設定してください。 

ステージング サーバーの設定がプロダクション環境を妨害しないように十分配慮してください。ステージング (または開発) サーバーを起動する前に、下記ヒントを一読してください。

3.1 Create a complete production backup using one of the alternatives below

  1. Using the Bitbucket Server Backup Client (not supported by Bitbucket Data Center)
  2. Bitbucket Server DIY Backup を使用する

3.2 プロダクション バックアップ全体のステージング環境へのコピー 

  1. ステージング サーバーをシャットダウンします。
  2. Restore the backup onto your staging environment using one of the methods you had it backed up 
    1. Restore from Backup Client to use a newly created DB
    2. Restoring a DIY Backup
  3. Verify your system environment variable BITBUCKET_HOME is set correctly. See Setting Bitbucket Server Home Directory for details.

3.3 ステージング環境に固有の設定

This is extremely important! Make sure your staging environment is not pointing to your production database. 

If you used DIY...
  • Configure your database connection to point to your staging database.  Edit the bitbucket-config.properties in BITBUCKET_HOME/shared
  • Fix your <BBS_HOME>/shared/server.xml . In case you had a reverse proxy you need to remove the reference to the old name, otherwise your new instance will redirect you to the production environment:
<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" />

If you're running Bitbucket Server 5.0+, the proxy configuration is made in bitbucket.properties and server.xml is no longer used.

tip/resting Created with Sketch.

If you are using a database (called BitbucketServerDB for example) with your existing Bitbucket Server installation and the database for your new Bitbucket Server installation is running on the same machine or database server, create your new database with a different name (e.g. something intuitive like BitbucketServerDB_402 for Bitbucket Server 4.0.2). Oracle does not support schema names with periods or underscores. Ensure the new database has identical access permissions to the old Bitbucket Server database.

If you used the Restore client...
  • The client will write the specified parameters to the  bitbucket.properties  file in the newly restored Bitbucket Server home directory bitbucket.properties in BITBUCKET_HOME/shared. This will all have been done as part of the Restore from Backup Client to use a newly created DB executed on step 3.2.
  • Fix your <BBS_HOME>/shared/server.xml . In case you had a reverse proxy you need to remove the reference to the old name, otherwise your new instance will redirect you to the production environment:

If you're running Bitbucket Server 5.0+, the proxy configuration is made in bitbucket.properties and server.xml is no longer used.


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

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

  1. Ensure the database is not pointing to production. To check this, see Viewing your System Information by going to Administration > Support Tools > Database Information. Check the 'Connection URL' to ensure it's pointing to the right place.
  2. Ensure emails are disabled or configured for dev server. (Administration > Mail server)

3.5 起動後の修正

  1. If you can't login. 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, logging out and start using the new admin account to perform your instance configuration.
  2. Modify the Site Base URL. See Specifying the base URL for Bitbucket Server and change the Site URL to the staging URL.
  3. Apply a Development License.  See our licensing FAQ to generate a license for the staging server. Refer to Updating your Bitbucket Server license details to apply it.
  4. Reconfigure applinks. If you are connecting to other servers via applinks, you'll need to change the server ID for those instances. 

    tip/resting Created with Sketch.

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

  5. Disable HipChat integration. If you have integrations which notify HipChat in any of your Bitbucket Server workflows, then you will need to remove the token from the HipChat integration configuration in Administration > Add Ons > HipChat Integration, to prevent HipChat notifications being sent from the staging environment.
  6. Ensure that no hooks are configured that will trigger builds if you are using CI tools. If you are using bamboo this will be taken care of when you disable application links. If you use something like Jenkins, you will need to manually disable or delete these hooks. 
  7. Plugins that impact repositories or build systems would need to be reviewed to make sure they are not impacting production systems. For example, if you are using the Mirror plugin, the connections would need to be edited so that pushes to the staging environment are not mirrored out to some external production system.


最終更新日 2019 年 6 月 18 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.