2020年5月26日火曜日

gliffy フリートライアルで画像ファイルを扱えなくなったので draw.io に乗り換えた

ブログなどで図を書いたりするときは、gliffy を利用していたのですがいつのまにか画像ファイルがフリートライアルで使えなくなっていたので、類似サービスの draw.io に乗り換えました。

使い方、UI が若干 gliffy とは違うので戸惑いますが、やりたいことは draw.io でも十分できました。
画像のアップロードも問題なく使えました。

しばらくは draw.io にお世話になりそうです。

VS Code 拡張が登場!!
そしてつい最近 VS Code で draw.io が使えるようになりました。
ブラウザ不要で .drawio または .dio 拡張子でファイルとして保存。テキストファイルなので管理(マージとか)も楽そうですし、仕様とかをリポジトリに紐付けやすくなりますね。
図をコードと同じように PR できるようになるので、これはすごく便利に使えそうだなと思いました。

今回は以上です。
では。


2020年5月18日月曜日

[CodeShip] Basic から Pro に移行してみたけど Basic に戻ってきた話

iutest の CI 環境アップデート報告その3です。
その1,2はこちら

今回は CodeShip の環境をアップデートしました。
CodeShip Basic と Pro とは
まずはじめに CodeShip について簡単に紹介します。

CodeShip は CloudBees が提供している CI as a Service です。
Basic はシンプルな機能で GUI Config なサービスです。
Pro は docker-compose のようにサービスコンテナを起動して CI ができるサービスです。

Pro の方が高機能で柔軟ですが、始めるには少し手間がかかります。
Basic はサービスが提供する環境でコマンドを実行する感じなので、すぐに始められます。

Basic と Pro はいつでもプロジェクト単位で移行可能です。
なので、とりあえず始めたい方には Basic がおすすめです。
Pro に移行してみた理由
iutest ではもともと Basic を使っていました。
ビルドや単体テストの実行などは行っておらず、 cpplint などのコーディングルールのチェックや OSDN の svn リポジトリへの同期、GitHub Pages のドキュメント更新を行っていました。
これらのことをする上で Pro の機能は必要なく Basic で十分でしたが、
ブログズミ: chrome://tracing で並列処理の可視化をしてみたらすごく便利だった話」で各 CI サービスの並列化能力を調べたところ、CodeShip Pro では Parallel Steps で多数の並列化(計測した限りでは 50 以上)可能だったため、Pro を使うことにしました。


Pro に移行
Basic から Pro に移行するにあたって必要なのは、YAML config の用意とプロジェクトのタイプ変更です。
YAML を用意する
まずは YAML ファイルを用意しましょう。
下記が iutest の YAML です。


CodeShip Pro で必要な YAML ファイルは2つあります。
services は docker-compose.yml みたいなものです。既存のイメージを pull するか Dockerfile からビルドできます。
steps に Basic で書いていたコマンドを書きます。
Pro の旨味を得るために、 Paralle Steps で並列に実行されるようにしています。

注意が必要なのは、Basic での環境では様々なツールがプリインストールされた環境だったので特にセットアップせずにツールが使えることが多かったですが、 Pro では docker image を使うので必要なツールや環境は自分で整える必要があります。

タイプ変更
YAML が準備できたらプロジェクトを Pro に変更します。
「Project Settings」の「General」にある「Change Project Type」で「Switch to CodeShip Pro」ボタンを押すだけです。

結果

Docker image のキャッシュが効いてる状態で多少速くなったかなーという結果でした。
やってることが軽量なのでこんなもんでしょう。ビルドやテストしてたら並列化の効果は高いと思います。
Basic に戻った理由
つづいて、Pro から Basic に戻った理由です。
Pro の並列化のメリットが iutest での使用例ではあまりなかったという理由もありますが、
一番の理由は「 OSDN の svn リポジトリへの同期処理で、SSH Key の設定を Pro でするのがめんどくさかったから」です。
Basic にはデフォルトで実行環境にプロジェクト固有の SSH Key が設定されており、Public Key をホストサービスに登録するだけで認証通せるので楽なのです。
(ここの設定画面は Pro に移行後も存在するのですが、この鍵は使えないようです。。)

もちろん Pro でも秘密鍵を取り扱う方法はちゃんと用意されています。
ただ、手間に見合うメリットがなかったので戻すことを決めました。
最後に
CodeShip Pro の Parallel Steps は上限がない?(少なくとも 50 並列できた)ので、かなり魅力的です。
CodeShip をメインの CI サービスにする場合は Pro をオススメします。

一方、CodeShip をサブの CI サービスにする場合は Basic で十分といえます。
Basic は並列化はできませんが、(私のように SSH Key の登録とか面倒なことを飛ばして)すぐにサービスを使いたい場合も Basic をオススメします。

Basic と Pro はプロジェクト単位でいつでも移行可能で、Web 上の設定は移行しても残ってたままになっているので気軽に乗り換えができます。
ぜひ一度、どちらも使ってみて使いやすい方を選んでください。

以上。

2020年5月11日月曜日

chrome://tracing で並列処理の可視化をしてみたらすごく便利だった話

前回「ブログズミ: [C++] -ftime-trace オプションと Chrome でビルド時間の可視化」の続きです。
chrome://tracing の活用として iutest で使用している CI サービスの並列具合を調べて可視化してみました。

レポート集計の構成
各 CI サービスから並列具合を可視化するために使用したのは、 Intergromat と Google スプレッドシートの2つです。
構成は下図のようになっています。


まず各 CI サービスからはジョブごとに処理の開始・終了時に、Integromat で用意した Webhook URL に情報を送信します。
各 CI サービスで並列化する方法は ci-parallel リポジトリ の YAML を確認してください。
Webhook には「CIサービス名」「commit hash」「名前」「並列番号」「時刻」「開始・終了イベント」などの情報が付与されて来ます。
その情報から、Integromat で Google Drive から CI サービスごとのスプレッドシートを検索し、そこにコミットごとにシートを作成して情報を書き込みます。


そこから Chrome の tracing で表示するための json ファイルに GAS を使って変換しダウンロードします。
あとは、ダウンロードした json ファイルを tracing で読み込めば可視化が完成です。
tracing 用 json への出力
chrome://tracing の json フォーマットはこちらを参考にしました。

function getData() {  
  var sheet = SpreadsheetApp.getActiveSheet();
  var maxRow = sheet.getLastRow();//行数 -
  var maxColumn = sheet.getLastColumn();//列数 |
  var keys = [];
  var ret = [];

  //1列目のkeyの名前取得
  for (var x = 1; x <= maxColumn; x++) {
    keys.push(sheet.getRange(1, x).getValue());
  }

  var base = 0;
  //データ
  for (var y = 2; y <= maxRow; y++) {
    var json = {};
    for (var x = 1; x <= maxColumn; x++) {
      var k = keys[x-1];
      var v = sheet.getRange(y, x).getValue();
      if( k == "ts" ) {
        var d = new Date(v);
        if( base == 0 ) {
          base = d.getTime();
        }
        v = (d.getTime() - base) * 1000;
      }
      
      json[k] = v.toString();
    }
    ret.push(json);
  }

  //整形してテキストに
  return JSON.stringify(ret, null, '\t');  
}
行のヘッダー名と要素は Integromat で tracing フォーマットに合わせて書き出しているので、ほぼほぼそのまま json にしています。
時間だけ最初のレコードを起点にした差分時間に変換しています。
結果
こんな感じになりました。

詳細は ci-parallel リポジトリを確認してください。
最後に
CI サービスの並列具合を可視化しようと思い、最初は BI ツールを転々と試していたのですが、 tracing がベストマッチでした。
もちろん何をどのように可視化したいかによって、 BI ツールを使うべき場合もありますが、可視化の選択肢として tracing は覚えておいて損はなさそうです。
そして、今回は単純な Duration イベントのみを使いましたが、他のイベントも使うともっといろいろな表現ができそうです。

メモリの追跡はありですね。やってみようかな。

あと、今回はスプレッドシート使いましたが、BigQuery とか使ったほうがイケてるのかな?
この辺今まで触ってこなかったので覚えていきたいですね。

宣伝

「技術書典 応援祭」で販売した本には今回調べた並列処理の比較はありませんが、次回作に向けて鋭意活動中です。そちらには収録を予定しています。
既刊および次回作をよろしくおねがいしますmm

今回は以上です。では。