5. 開発機(Linux)での設定

git flow の設定

SourceTree の開発が簡単なので、ここまでの設定は Mac 上でやっていた。そろそろ ubuntu 開発機の方でも同じ事ができるように調整する。以下は Linux 上での作業になる。こちらには git-flow が入っていなかったので、ansible 経由により apt でインストールする。

次に、git flow が使えるように初期化する。

$ git flow init

Which branch should be used for bringing forth production releases?
   - master
Branch name for production releases: [master] 
Branch name for "next release" development: [develop] 

How to name your supporting branch prefixes?
Feature branches? [feature/] 
Release branches? [release/] 
Hotfix branches? [hotfix/] 
Support branches? [support/] 
Version tag prefix? [] 

SourceTree と同様に master と develop ブランチが作成され、develop に移動している。ここでも同様に編集する可能性があるので、feature/configure_systems ブランチを取得しておく。

$ git flow feature track configure_systems
Branch feature/configure_systems set up to track remote branch feature/configure_systems from origin.
Switched to a new branch 'feature/configure_systems'

Summary of actions:
- A new remote tracking branch 'feature/configure_systems' was created
- You are now on branch 'feature/configure_systems'

その後、こちらでも rspec 等の設定をして、/bin/rspec が動作するところまでを確認する。

Jenkins の設定

Jenkins は開発サーバの Linux にインストールする。当然ながらすべての設定は ansible にて行う。インストール後に Jenkins の設定でやったことを記録しておく。

  • グローバルセキュリティの設定で「セキュリティの有効化」
  • Jenkins のユーザーデータベースでサインアップの許可
  • サインアップして hkob ユーザを作成
  • 「サインアップを許可」を外す
  • プラグインの管理の高度な設定で、HTTP Proxy を設定
  • プラグインのアップデート
  • 以下のプラグインをインストール
    • Git Plugin
    • role-strategy
  • グローバルセキュリティの設定にて権限管理を Role-Based Strategy に設定
  • Jenkins の管理に「Manage and Assign Roles」ができているので、Role の権限やユーザを見直す。現在は、hkob のみ admin で他のユーザは作っていないため、Jenkins のログインをしないと何も見えない状況になった。

Jenkins ジョブの作成

今回のシステムの自動テストを行いたいので、Jenkins ジョブを作成する。feature のコミットは Guard によるローカルテストで実施するので、サーバのテストは develop ブランチにマージがされた時でよいかと考えている。ブランチモデルでの Jenkins の設定は初めてなので、試行錯誤でやってみる(現在のシステムも Jenkins 管理なので、設定画面を横で見ながら同じように設定してみる)。ただし、現在のシステムは特定の場所にインストールされた Ruby だったが、今回は rbenv を目的としているため、いくつか変更が必要だった。

  • 新規ジョブ作成をする
  • ジョブ名は dev-webcit3 とし、フリースタイル・プロジェクトのビルドとする
  • ソースコード管理は Git、リポジトリは同一マシンなのでパスを直接書く
  • Branches to build を */master から */develop に変更する
  • Git リポジトリの更新時に自動テストをしたいので、「リモートからビルド」をチェックする。認証トークンを適当なものに設定する
  • ビルドのシェルスクリプトを設定する。rbenv の設定、プロキシの設定、bundle の実行、rspec の実行までをやってみる

この状態でビルドしたが、何もないのでエラーになった。

Git フックの作成

このサーバにある親リポジトリに develop が push された時に build を実行するスクリプトを設定する。Linux サーバにある bare リポジトリの hooks ディレクトリで post-update を置けばよい。以前は、post-receive だったが、develop だけを抽出したいので、ブランチごとに処理される post-update に変更している。作業手順は以下の通り

  • Jenkins のユーザ名をクリックし、設定を開く
  • API トークンを表示で、32 文字のトークンを記録しておく
  • cd bareリポジトリ/hooks で hooks に移動
  • cp post-update.sample post-update
  • post-update の中身を以下の様に記述
#!/bin/sh
#
# An example hook script to prepare a packed repository for use over
# dumb transports.
#
# To enable this hook, rename this file to "post-update".

#exec git update-server-info

BRANCH=$(git rev-parse --symbolic --abbrev-ref $1)
case $BRANCH in
	develop)
		echo "Hook post-update start"
		/usr/bin/wget --auth-no-challenge --http-user=hkob --http-password=APIトークン http://localhost:8080/job/ジョブ名/build?token=ジョブの設定で付けたビルドトークン -O /dev/null || echo "wget failed"
		echo "Hook post-update end"
esac
  • このスクリプトの引数に refs/heads/ブランチ名が入ってくるようなので、BRANCH というシェル変数にブランチ名を記述 (参考:gitのpost-updateフックでブランチ名を取得する
  • http-password にはユーザの API トークンを、token= のところにビルド設定で付けたビルドトークンを書く
  • シェルに実行属性を付けておく。以下はシェルスクリプトの動作確認
    • 「./post-update refs/heads/master」のようにしてビルドが起動しないことを確認
    • 「./post-update refs/heads/develop」のようにしてビルドが起動することを確認
  • 後は develop へのマージ後の git push でビルドが発火するかどうか

feature ブランチの develop へのマージ

feature ブランチで rspec が動いていることを確認したので、ここまでを develop にマージしてみる。この結果、Jenkins で自動テストが動くかどうかも確認する。

それでは develop を feature/configure_systems とマージしてみる。手順は以下の通り

  • ブランチの develop をクリックしてみる。いろいろなファイルが消えてしまっていることがわかる(ただし、Git 管理外のファイルが残るのでディレクトリがいくつか残ってしまっている)。
  • SourceTree でマージをクリックし、feature/configure_systems を選択してマージする
  • 今回はコンフリクトは起こっていないので、問題なく develop が feature/configure_systems に追いついた
  • サーバ側の origin/develop が遅れているので、push に数字が表示されている
  • プッシュをする前に、Jenkins の画面を別に開いておく
  • 残念ながら発火しなかったので、調査
  • Gemfile を少しいじってみてテスト
  • proxy が自動的に適用されてアクセスできなかったので、http_proxy を無効にしてみた
  • 動作を確認
  • ただし、Jenkins が文字化けをしている
  • /etc/default/jenkins に -Dfile.encoding=utf-8 を追加する

テストで haml を追加してしまったので、bundle install の結果を記録しておく。

$ bundle install
Fetching gem metadata from https://rubygems.org/.........
Installing haml 4.1.0.beta.1
Installing hpricot 0.8.6
Installing sexp_processor 4.4.4
Installing ruby_parser 3.1.3
Installing html2haml 1.0.1
Installing haml-rails 0.6.0
Your bundle is complete!
It was installed into ./vendor/bundle
Post-install message from haml:

HEADS UP! Haml 4.0 has many improvements, but also has changes that may break
your application:

* Support for Ruby 1.8.6 dropped
* Support for Rails 2 dropped
* Sass filter now always outputs <style> tags
* Data attributes are now hyphenated, not underscored
* html2haml utility moved to the html2haml gem
* Textile and Maruku filters moved to the haml-contrib gem

For more info see:

http://rubydoc.info/github/haml/haml/file/CHANGELOG.md

今日はここまで。

written by iHatenaSync