Logic Delight

明日のワシは忘れてしまうから、コードにはコメントを書くのです。

Jenkinsオジサンからの卒業その4(werckerを試してみた)

CI Tools

Wercker

wercker.com

git push からのビルドとデプロイを自動化することを目的に作られたサービス。ビルドの後続処理をPipelineで繋いでいけるのが醍醐味らしい。

使い方

  • アカウントの作成は、独自アカウント作成 or GitHub連携で可能
  • 自動ビルドさせたいリポジトリを選択する
  • 対象リポジトリの設定を幾つかやる
    • deploy key の自動登録を任せるのが一番楽
  • 対象リポジトリのルートに wercker.yml を配置する
    • ここで気付いたけど、werckerがデフォルトで yml サンプル定義を提供しているのは、 GoLang, NodeJS, Python, Ruby ということが判明し、もしやJavaには対応していないんじゃないのorz として企画に幕を下ろしかけた
      • けども、いやまてよ。Dockerコンテナでコマンド実行するだけの汎用的な仕組みなら java 用のコンテナを指定しつつ Drone.io と同様に gradlew とかでビルドできるのではないか
  • ということで、Java ビルドがしたければ、ボックスの指定を box: java:8 とかにするべし
    • Gradleを使いたい場合は、gradlew 一式をリポジトリにcommitすること推奨
      • ビルドコマンドはこんな感じ
steps:
  - script:
      name: gradlew
      code: |
        ./gradlew
  - script:
      name: gradle build and test
      code: |
        ./gradlew check

色々と試行錯誤をしましたが、結果的にはちゃんとビルドできました☆

自動ビルドのトリガー

  • Push
    • default branch 以外のPushもブランチを区別してビルド結果を残してくれる
  • GitHub上のPRとも連携してくれる
    • ビルドがとおったPR(commit)か？が確認できて便利

ビルド結果

  • build badge のURLを提供
    • 過去数回分のビルド結果がRed/Greenの色分けで見れて、コードの安定度の目安にできるかも
  • ビルド成果物(Artifacts)の保存
    • できるのかもしれないけど、方法わからず
  • Mail通知
  • Slack通知

初めはヒントが少なくて戸惑いましたが、UIもイケてるし、多重度2まではFreeで使えるし、リポジトリ＆開発者は無制限な模様。なかなか良い感じなのではないかと。

その他

  • 内部的にはコンテナ上でビルドが走る
    • 各ステップの詳細ログが見れる
  • UIはいい感じに今風
  • そういえば、醍醐味である自動デプロイや、Pipeline設定は試していなかった...

SampleでWerckerビルドを設定してみたリポジトリはコチラ
https://github.com/shionit/sample-wercker

Jenkinsオジサンからの卒業その3(Drone.ioを試してみた)

CI Tools

Drone.io

Continuous Integration · drone.io

GitHub以外のVCSホスティングサイトとの連携もでき、OSSなのでオンプレ環境でも利用可能。細かい機能面は今後に期待、か。以下は、OSS版ではなく https://drone.io/ で試したもの。

使い方

  • アカウントの作成は、GitHub連携・BitBucket連携・Google連携で可能
  • 自動ビルドさせたいリポジトリを選択する
    • 標準で対応しているビルド構成でよければ、これだけでビルド実行できる
    • 対応していないビルド構成の場合は、ビルド用のコマンドを drone.io の Settings ページで入力する必要がある
  • Java デフォルトで対応しているビルドスクリプトは Ant, Maven
    • Gradleを使いたい場合は、gradlew を推奨とのこと
      • gradlew をリポジトリにcommitしておく必要あり
      • ビルドコマンドはこんな感じ
chmod +x gradlew
./gradlew [task]
  • リポジトリ内にビルド設定を定義できない？？
    • .drone.yml を置いたのに、読んでくれない？OSS版だけの機能なのか？？
      • だとしたら非常に残念
      • 2016/07/28追記 OSS版では .drone.yml を読み込んでくれました

自動ビルドのトリガー

  • Push
    • default branch 以外のPushもビルド
  • GitHub上のPRと連携してくれない
    • ビルドがとおったPR(commit)か？は確認できない

PRと連携できていないのは残念。

ビルド結果

  • build badge のURLを提供
    • build badge 表示はlatest（最後に実行したビルド）のみ
  • ビルド成果物(Artifacts)の保存
    • マスタービルドで生成されるJar/Warを指定しておくと、Downloadが可能
  • Mail通知
  • ビルド後のデプロイタスクも設定可能

単純なビルドの成否を出力・通知するだけのTravisCIとの大きな違いとして、Artifactsの保存やデプロイタスクがある。branchごとではなく、とにかく最後にビルドした結果が残るという仕様が、少し残念なところ。

その他

  • 内部的にはコンテナ上でビルドが走る
    • 各ステップの詳細ログが見れる
  • UIは良く言えばシンプル、なんか物足りなくも感じる...

SampleでDrone.ioビルドを設定してみたリポジトリはコチラ
https://github.com/shionit/sample-droneio

Jenkinsオジサンからの卒業その2(CircleCIを試してみた)

CI Tools

Circle CI

circleci.com

GitHubとの親和性は高く、手軽に使えていい感じ。

使い方

  • Circle CI にGitHubアカウントでログイン
  • 自動ビルドさせたいGitHubリポジトリを選択する
    • これだけでビルド実行できる
  • 対象のリポジトリに circle.yml を置かなくてもビルドは可能のようだが、今回試したJavaプロジェクト(TravisCIで試したものと中身は同一)では置かないとビルドが通らなかった

自動ビルドのトリガー

  • Push
    • default branch 以外のPushもビルド
  • Pull Request
    • 追加Pushで再ビルド

Travis CIと遜色ない印象。

ビルド結果

  • build badge のURLを提供
  • ビルド成果物(Artifacts)の保存
    • マスタービルドで生成されるJar/Warの他に、単体テストレポートや静的解析ツール実行結果も残しておけるので、閲覧が可能
  • Mail通知
  • Slack通知
  • ビルド後のデプロイタスクも設定可能

単純なビルドの成否を出力・通知するだけのTravisCIとの大きな違いとして、Artifactsの保存やデプロイタスクがある。

その他

  • 内部的にはコンテナ(デフォルトではUbuntu)上でビルドが走る
    • ビルドの各ステップの処理時間が確認できる
    • 各ステップの詳細ログが見れる
  • ビルド用コンテナにsshしてビルド失敗原因の調査や細かな環境設定が可能
  • テスト実行の並列度など細かな設定が可能
    • 複数コンテナで並行実行させるには有償プランにする必要あり
  • build スクリプトは自動検出
    • TravisCIと同様

SampleでCircleCIビルドを設定してみたリポジトリはコチラ
https://github.com/shionit/sample-circleci

Jenkinsオジサンからの卒業その１（TravisCIを試してみた）

Tools CI

Travis CI

Travis CI - Test and Deploy Your Code with Confidence

GitHubとの親和性は高く、手軽に使えていい感じ。

使い方

自動ビルドのトリガー

  • Push
    • default branch 以外のPushもビルド
  • Pull Request
    • 追加Pushで再ビルド

ビルド結果

  • build badge のURLを提供
  • Mail通知
  • Slack通知
  • ビルドがSuccessかFailか？の結果を出すシンプルな出力
    • Test結果のレポート表示はできない
    • ビルド成果物(artifacts)の保存もできない

その他

SampleでTravisCIビルドを設定してみたリポジトリはコチラ
https://github.com/shionit/chronos

自習系GitHubリポジトリをひとつにまとめてみた

Git Mac

厳密には、"今日覚えたこと"を書いていくという、一部で流行りの気配を見せている til (Today I learned) リポジトリの真似をして、自習系リポジトリをまとめてみた、という記事ですな。

(切欠) GithubでTILというリポジトリが流行りつつあるのかもしれない - 生涯未熟

元リポジトリ（４つ）

  • black-hat-python
  • electron-sample
  • GlibTraining
  • Python-handson

出来上がり状態

  • til
    • README.md
    • black-hat-python
    • electron-sample
    • GlibTraining
    • Python-handson

github.com

新設した til リポジトリに各リポジトリを内包させる形で git filter-branch していく。各リポジトリのコミット履歴は残り、元リポジトリの名称のブランチから master にマージされたかたちになる。

参考にしたサイト

qiita.com

コメント欄にあるとおり、本文中の git filter-branch の部分がMacだとエラーになってしまうので、コメントにあるコマンドを使った。

また、electron-sample リポジトリは、直下に同名のディレクトリが存在していたので、これを src にリネームしたうえで実施してみたが、「コミット履歴中にリポジトリ名と同名のフォルダが存在すると...」というこれまたコメント欄にあるとおりのエラーになったので、こちらもMac版のコマンドに修正したうえで実施した。

つまり、まとめると

#GitHub Account
ACCOUNT=shionit
#Source Repository
REPO=XXXXX

# at dest repository path
git remote add $REPO git@github.com:$ACCOUNT/$REPO.git
git fetch $REPO
git checkout -b $REPO $REPO/master
git filter-branch -f --tree-filter "mkdir __temp__ && git mv -k {,.[!.],..[!.]}* __temp__/ && mkdir $REPO && git mv -k __temp__/{,.[!.],..[!.]}* $REPO/"
git checkout master
git merge $REPO

結果、単一の自習リポジトリにまとめられてスッキリですな☆

Mac環境構築の自動化と設定バックアップ

Mac

以下の記事を参考に、Home Brew と Brew Cask を使って環境構築の自動化（省力化）をしてみた。

qiita.com

他にも、Ansibleを使ったMac環境構築の記事はありましたが、AnsbileのバージョンUp時の仕様変更についていくのツライ、Brew Bundleがいい感じにメンテされていきそう、mackupもシンプルで素敵☆ということで上記の記事に沿って対応することにしました。

上記の記事では brew brewdle コマンドを使っていますが、GitHubの本家リポジトリを見る限り brew brewdler brew bundler といったコマンドとともに下位互換性を保つためのエイリアス実装となっており、今後は brew bundle が公式なコマンドとなっていくものと思われるので、これで実装しといた。

GitHub - Homebrew/homebrew-bundle: Bundler for non-Ruby dependencies from Homebrew

他にも参考にした記事、というかbrewで取得するアプリケーションの一覧を覗くだけでも、知らない便利アプリに出会うことができて有意義でした。

Mac の開発環境構築を自動化する (2015 年初旬編) - t-wadaのブログ

既存環境のMac でもansible で環境構築を自動化するには - snowlongの日記

2016/04/21追記

便利な mackup がバージョンアップしてオプション指定方法が変わったのか、パラメータを変えてあげないと動かなくなったのでメモ。

@daily /usr/local/bin/mackup -f backup

2016/07/28追記

Home brew cask の Caskroom のデフォルトロケーションが変更されたこと*1に伴い、crontabの内容を見直す必要ができたのでメモ。

@weekly cd /usr/local/bin/ && time nice -n19 brew update && time nice -n19 brew upgrade && time nice -n19 brew cleanup && for c in `brew cask list`; do ! brew cask info $c | grep -qF "Not installed" || time nice -n19 brew cask install $c; done && time nice -n19 brew cask cleanup && for c in /usr/local/Caskroom/*; do vl=(`ls -t $c`) && for v in "${vl[@]:1}"; do \rm -rf "$c/$v"; done; done; for c in /usr/local/Caskroom/*/.metadata; do vl=(`ls -t $c`) && for v in "${vl[@]:1}"; do \rm -rf "$c/$v"; done; done

dotfilesの整備

また、GitHub に公開されている dotfiles 系リポジトリを参考にシェルまわりの環境設定も合わせて整備した。

GitHub - mathiasbynens/dotfiles: .files, including ~/.macos — sensible hacker defaults for macOS

GitHub - yuku-t/dotfiles: My dotfiles

初期設定まわりが随分とスッキリして、バックアップも取れて安心安心☆というのもありますが、個人的には .gitconfig にgitコマンドのエイリアスを定義しまくって効率化！というのを色々とキャッチアップできたのが大変有用でした。最後に、出来上がったdotfilesはコチラ↓

github.com

*1:https://github.com/caskroom/homebrew-cask/issues/21913

Dockerのバージョンアップしたらコマンドがエラーになった

Docker

Dockerのバージョンアップ（1.9.1->1.10.1）したら、dockerコマンドがエラーを返すようになった。

$ docker ps
Error response from daemon: client is newer than server (client API version: 1.22, server API version: 1.21)

サーバーの再起動なり、アップグレードをすることで解消する模様。

$ docker-machine upgrade
Waiting for SSH to be available...
Detecting the provisioner...
Upgrading docker...
Stopping machine to do the upgrade...
（中略）
Restarting docker...

$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES

直った。良かった。

（参考URL）
Error response from daemon: client is newer than server with Docker 1.9 RC3 · Issue #2147 · docker/machine