こんにちは。開発本部の 稲本 です。医療介護の求人サイト「 ジョブメドレー 」の開発を担当しているエンジニアです。 最近ジョブメドレーでは CircleCI2.0 への移行を行いました。移行の方法はもちろん、その際に調べたこと、CircleCI の新機能を利用してどうだったかなどを書いていきたいと思います。 課題感 弊社では、全プロダクト( CLINICS 、 MEDLEY 、 介護のほんね 、 ジョブメドレー )で CircleCI を利用しています。 ジョブメドレーでは CI によるテスト実行に 37 分前後掛かっていました(コンテナを 2 つ利用した実行時間です)。 さらに、開発メンバーが増えて来たこともあり、CI のリソースが足りなくなり開発効率が落ちかねない状況でした。 まぁよくある話ですよね。 コンテナを増やすというのも解決策の一つとしてはあるのですが、速度の改善に期待が出来ると評判も良かったので CirclecCI2.0 へ移行しました。 CircleCI2.0 への移行メリット 基本的には速度の改善に期待が出来る、というのが大きなメリットではありますが、公式では以下のように記載されています。 抜粋ですが大きな特徴としては以下の点でしょうか。 First-class Docker Support: Docker のネイティブサポートと Docker レイヤーキャッシュの導入 Workflows: ビルド、テスト、デプロイをジョブとして柔軟に管理できるようになった Advanced Caching: キャッシュの保存とリストアをイメージ、ソースコード、依存関係に対して行うことができるようになった。 この辺りの機能を活用し CI の速度改善へ繋げてみたいと思います。 ジョブメドレーのアプリケーション構成 移行の前提として、ジョブメドレーのアプリケーション構成について記載します。 フロントエンドのビルドを yarn+webpack で行い、生成したアセットを public/assets へ吐き出し、manifest ファイルのパスを rails の helper 経由で取得し読み込んでいます。（Rails4.2.x） このような構成のアプリケーションを CirlceCI2.0 でビルド、テスト、デプロイ出来るようにしていきます。 config.yml の全体像 今回、作成した config.yml はこのような形になりました。 ざっくりは build: bundle install, yarn install code_analyze: rubocop, brakeman, scss-lint rspec deploy: capistrano を行っており、ブランチによってどのジョブを実行するのかを workflows を利用して使い分けています。 詳しい解説は以降、記載していきます。 defaults : & defaults working_directory : ~/job-medley docker : - image : circleci/ruby:2.4.2-node-browsers environment : TZ : /usr/share/zoneinfo/Asia/Tokyo - image : circleci/mysql:x.x.x environment : TZ : /usr/share/zoneinfo/Asia/Tokyo - image : redis:x.x.x environment : TZ : /usr/share/zoneinfo/Asia/Tokyo version : 2 jobs : build : << : * defaults steps : - checkout - restore_cache : key : job-medley-app-{{ checksum "Gemfile.lock" }} - run : name : bundle install command : bundle install --jobs=4 --path=vendor/bundle - save_cache : key : job-medley-app-{{ checksum "Gemfile.lock" }} paths : - vendor/bundle - restore_cache : key : job-medley-yarn-{{ checksum "yarn.lock" }} - run : name : Yarn install command : | echo "Node $(node -v)" echo "Yarn v$(yarn --version)" yarn config set cache-folder ./yarn_cache echo "Yarn v$(yarn cache dir)" yarn install - save_cache : key : job-medley-yarn-{{ checksum "yarn.lock" }} paths : - node_modules - yarn_cache - persist_to_workspace : root : ~/job-medley paths : - ./* code_analyze : << : * defaults steps : - attach_workspace : at : ~/job-medley - run : name : run rubocop command : bundle exec rubocop - run : name : run brakeman command : bundle exec brakeman -qz - run : name : run scss-lint command : bundle exec scss-lint rspec : parallelism : 2 << : * defaults steps : - attach_workspace : at : ~/job-medley - restore_cache : key : job-medley-elasticsearch # rspec で es のコマンドを一部実行しているため、primary container 側へ install - run : name : Elasticsearch install command : | wget https://download.elasticsearch.org/elasticsearch/elasticsearch/elasticsearch-x.x.x.tar.gz && \ tar -xvf elasticsearch-x.x.x.tar.gz && \ if [ -z "`elasticsearch-x.x.x/bin/plugin -l | grep analysis-kuromoji`" ]; then \ elasticsearch-x.x.x/bin/plugin -install elasticsearch/elasticsearch-analysis-kuromoji/x.x.x; fi - save_cache : key : job-medley-elasticsearch paths : - ./elasticsearch-x.x.x - run : name : database create command : bundle exec rake db:create environment : RAILS_ENV : test - run : name : run test command : | circleci tests glob 'spec/**/*_spec.*' \ | circleci tests split --split-by=timings --timings-type=filename \ | tee -a /dev/stderr \ | xargs bundle exec rspec \ --profile 100 \ --format RspecJunitFormatter \ --out rspec/rspec.xml \ --format progress environment : RAILS_ENV : test TEST_CLUSTER_COMMAND : elasticsearch-x.x.x/bin/elasticsearch - store_artifacts : path : artifacts/ - store_test_results : path : rspec/ deploy_qa : << : * defaults steps : - attach_workspace : at : ~/job-medley - run : name : run deploy command : | sh scripts/init_deploy.sh BRANCH="${CIRCLE_BRANCH}" bundle exec cap develop deploy deploy:restart deploy_only : << : * defaults steps : - attach_workspace : at : ~/job-medley - run : name : run deploy command : | BRANCH="${CIRCLE_BRANCH}" bundle exec cap production deploy deploy:restart workflows : version : 2 workflows : jobs : - build - code_analyze : requires : - build filters : branches : ignore : /^sandbox.*|^master$|^staging$/ - rspec : requires : - build filters : branches : ignore : /^sandbox.*|^master$|^staging$/ - deploy_qa : requires : - code_analyze - rspec filters : branches : only : develop - deploy_only : requires : - build filters : branches : only : /^sandbox.*|^master$|^staging$/ DockerImage の選定 元々、Docker を使わずに CI を回していましたが、CircleCI2.0 へ移行するに辺り Docker への利用に切り替えました。 ※ Specifying Container Images DockerImage は DockerHub へ登録されている CircleCI 公式のも の を利用しました。 アプリケーションの一部で React を使用しており、フロントのビルドは yarn+webpack を利用しています。その為、以下の image を選択しました。 circleci/ruby:2.4.2-node-browsers node のインストールと、E2E のテストに必要なソフトウェアがインストールされています。 ※詳細は こちらの記事 を参考にさせていただきました。 その他、現在利用している MySQL のバージョン、ElasticCacheRedis のバージョンと合わせた image を選択しました。 注意点としては、複数の DockerImage を利用する場合、一つ目に指定した image が primary として扱われます。 以下の例ですと、Ruby の image を最初に指定し、MySQL、Redis の image を指定していますが、MySQL コマンド自体は Ruby の image に含まれていないため、Ruby コマンドを実行できても MySQL コマンドを実行することは出来ません。 ※詳細は こちら に記載されています。 docker : - image : circleci/ruby:2.4.2-node-browsers environment : TZ : /usr/share/zoneinfo/Asia/Tokyo - image : circleci/mysql:x.x.x environment : TZ : /usr/share/zoneinfo/Asia/Tokyo - image : redis:x.x.x environment : TZ : /usr/share/zoneinfo/Asia/Tokyo また、用意されている image をカスタマイズする必要がある場合は、Docker でカスタム image を作り、public で良ければ Docker Hub へ登録、private が良ければ Amazon EC2 Container Registry へ登録しておくことで呼び出すことも可能になっています。 ※Using Custom-Built Docker Images https://circleci.com/docs/ja/2.0/custom-images/ ※Using Private Images https://circleci.com/docs/ja/2.0/private-images/ build の設定と cache CI で実行するアプリケーションの build に関してです。 checkout で github からコードを checkout し、その後の定義でアプリケーションのインストール、キャッシュ保存、キャッシュの展開を行っています。 steps : - checkout # Rails application setup - restore_cache : key : job-medley-app-{{ checksum "Gemfile.lock" }} - run : name : bundle install command : bundle install --jobs=4 --path=vendor/bundle - save_cache : key : job-medley-app-{{ checksum "Gemfile.lock" }} paths : - vendor/bundle save_cache: key に Gemfile.lock を指定することでキャッシュキーとして扱い、paths に設定したパスをキャッシュするようにしています。 restore_cache: key と一致するキャッシュがあれば、save_cache 時に指定したパスを展開し直しています。 run: こちらは rails のアプリケーションインストールしているだけです。 CircleCI1.0 よりもキャッシュ管理を柔軟に行えることがわかります。 circleci コマンドによる Rspec の並列実行 rspec によるテストの実行に関してです。 circleci コマンド を利用することでテストの並列実行を効率的に行うことが出来るます。 今回は --split-by=timings --timings-type=filename のオプションを指定し、ファイル名ベースでの分割でテストを実行します。 - run : name : run test command : | circleci tests glob 'spec/**/*_spec.*' \ | circleci tests split --split-by=timings --timings-type=filename \ | tee -a /dev/stderr \ | xargs bundle exec rspec \ --profile 100 \ --format RspecJunitFormatter \ --out rspec/rspec.xml \ --format progress environment : RAILS_ENV : test TEST_CLUSTER_COMMAND : elasticsearch-x.x.x/bin/elasticsearch - store_artifacts : path : artifacts/ - store_test_results : path : rspec/ store_artifacts: 以前からもある機能ですが、テスト結果の成果物を保存するパスになります。 store_test_results: こちらはテストの実行結果を保存しておくことで、コンテナ間で rspec の実行時間にばらつきが出ないよう、対象のファイルを最適に振り分けてくれるようなのですが、workflows を利用するとサポートされないようです。 ※参考： https://circleci.com/docs/ja/2.0/configuration-reference/#store_test_results このような形で Artifacts が保存されています。 また、artifacts には coverage と capybara の screenshot などを保存しています - simple_cov if ENV['CI'] SimpleCov.coverage_dir File.join(ENV['CIRCLE_WORKING_DIRECTORY'], 'artifacts', 'coverage') SimpleCov.formatter = SimpleCov::Formatter::MultiFormatter[ SimpleCov::Formatter::HTMLFormatter ] SimpleCov.start do add_filter '/vendor/' add_filter '/spec/' add_filter '/config/' add_filter '/db/' end end capybara Capybara.save_and_open_page_path = File.join(ENV['CIRCLE_WORKING_DIRECTORY'], 'artifacts', 'capybara') if ENV['CI'] ※CircleCI2.0 から CI の環境変数が変わっています。詳細は以下のリンクへ記載されています。 Introduction to environment variables - CircleCI Introduction to environment variables in CircleCI circleci.com Workflows の設定 CircleCI2.0 から Workflows の利用が可能になりました。 Workflow orchestration - CircleCI Learn about using CircleCI workflows to orchestrate jobs circleci.com コンテナ毎に分割しジョブを実行することで更なる並列実行の効率化、及び、ジョブ間の依存関係まで設定できるようです。 ジョブメドレーではコードの静的解析に少し実行時間が掛かっていることから、多少の改善を図れると考え 単純に使ってみたかった こちらの機能を利用してみました。 workflows : version : 2 workflows : jobs : - build - code_analyze : requires : - build filters : branches : ignore : /^sandbox.*|^master$|^staging$/ - rspec : requires : - build filters : branches : ignore : /^sandbox.*|^master$|^staging$/ - deploy_qa : requires : - code_analyze - rspec filters : branches : only : develop - deploy_only : requires : - build filters : branches : only : /^sandbox.*|^master$|^staging$/ build: 各ジョブで実行前に行っておく処理を定義 code_analyze: rubocop、brakeman、scss-lint などの静的解析処理を定義 rspec: アプリケーションのテストを定義 deploy: デプロイに関する処理を定義 ジョブメドレーでは、ブランチ管理に Git-flow を採用していますが、それとは別に sandbox というテスト環境を用意し運用しています。 develop ブランチでコード解析やテストをクリアしたコードだけ、master へ反映し、master ではテストフェーズなしに deploy する構成を取っています。 極力、CI のリソースを節約するように各ブランチごとで実行する処理を分けています。 各ブランチの運用は以下の通りです。 feature: コード解析、テスト実行 sandbox: デプロイのみ実行(一時レビュー用ブランチ) develop: コード解析、テスト実行、デプロイ実行 master: デプロイのみ実行 上記の例では、 code_analyze: sandbox、master、staging ブランチ以外は実行 requires で依存関係を指定し、build が正常に終了しなければ実行されないようになっています。 rspec: sandbox、master、staging ブランチ以外は実行 requires で依存関係を指定し、build が正常に終了しなければ実行されないようになっています。 deploy_qa: develop ブランチでのみ実行 requires で依存関係を指定し、code_analyze、rspec が正常に終了しなければ実行されないようになっています。 deploy_only: sandbox、master、staging ブランチのみ利用するジョブ requires で依存関係を指定し、build が正常に終了しなければ実行されないようになっています。 どのような workflow が出来あがるのか、以下に例を示します。 feature ブランチの例: develop ブランチの例: master、sandbox ブランチの例: 今回の例だとブランチ毎に workflow を変えているため、ignore、only の書き方で意図せず振り分けされないように考慮は必要ですが、柔軟に workflow を作れることがわかると思います。(やり過ぎると読み解くのが大変になりそうですね) Workflows に関しては こちら に色々なパターンの組み方が記載されているので、こちらを読むとより理解が深まると思います。 ジョブ間でのデータ共有 ジョブを分けてビルドする=何回もアプリケーションの初期化が必要なんじゃないか？ と当然疑問に思う点ではありますが、それに対する解決策も用意されています。 build : steps : ===省略=== - persist_to_workspace : root : ~/job-medley paths : - ./* deploy_qa : << : * defaults steps : - attach_workspace : at : ~/job-medley persist_to_workspace: 指定したパスにあるデータを一時的に保管してくれます attach_workspace: 保管済みのデータを展開してくれます この機能により、ビルドプロセスで生成したものを各ジョブで実行するコンテナへ渡すことが出来ます。 ただし、そもそもビルドプロセスでキャッシュを入れていることもあり、これ自体の効果は殆どありませんでした。 コンパイル済みのデータを受け渡す際には効果を発揮しそうですね。( 公式でも そのような利用を想定していそうです) 改善結果 肝心の速度改善結果です。結果は以下の通りになりました。 改善前: CircleCI1.0 rspec の実行時間: 26:59 以下は、CircleCI2.0 へ移行しただけの結果です。このケースでは workflows を利用していません。 改善後: CircleCI2.0 rspec の実行時間: 19:40 CircleCI1.0 から CircleCI2.0 へ移行することにより、 約 12 分程 テストの実行時間を短縮することが出来ました。 Workflows など特に利用していない、かつ、ビルドフェーズの実行時間も関係しないため、CircleCI2.0 を利用するだけで単純にテスト実行速度の向上を見込めることがわかると思います。 続いて Workflows を利用した結果です。 改善後: CircleCI2.0 with Workflows rspec の実行時間: 21:14 結果は、Workflows を利用しないケースと、利用したケースでは、Workflows を利用したほうが rspec の実行時間は長くなってしまいましたが、build-code-analyze-rspec の実行に掛かったトータルの時間に差は見られませんでした。 これは、「circleci コマンドによる Rspec の並列実行」のセクションへも記載した通り、store_test_results がサポートとされないことにより、コンテナ間での分散が最適化されていない為です。 コンテナ間で rspec の実行時間にばらつきが出ないよう、対象のファイルを最適に振り分けてくれるようなのですが、Workflows を利用するとサポートされないようです。 実行時間にばらつきが出てしまい、code_analyze のジョブを分散することで見込んでいた改善時間(約 3 分)とばらつきにより発生したテスト実行時間のロス( (20:01 - 14:57) / 2 = 2:32 )が大体同じであるため、トータルでの実行時間に差が出ない結果となりました。 ばらつきを出さない方法や、ジョブの分け方については今後も工夫してみたいと思います。 また、フロントエンドのテストをもう少し厚くしていきたいと考えているので、フロントエンドのテスト、サーバサイドのテストを Workflows を上手く使いながら分散していければ良いのかなとも思っています。 さいごに 移行に際して、 CircleCI2.0 の移行ガイド を読みながら進めていましたが、基本的な記法の変更、timezone、environment の定義方法の変更、variable の変更などが多々有り、ドキュメントを結構読み込まないとどこに何が定義できるのか把握できませんでした。 また、Workflows の組み立てなど 公式に良いサンプル は沢山あるのですが、依存関係の定義を色々試すのに苦労した気がします。 ※素直に小規模なアプリを用意して、 ローカルで circleci を実行 してみた方が効率良く進められたかもしれません。 ※ただ、 公式のドキュメント や CommunityForum をしっかり読めば余すことなく情報は合ったので非常に助かりました。 CircleCI2.0 でどのような事が出来るのか、それはどのように行えるのか。 この記事がその概観をつかむ助けになれば良いなと思っています。 参考リンク CircleCI2.0 へ移行するにあたり、以下の記事を参考にさせていただきました。ありがとうございます。 circleci/ruby:2.4.1-node-browsersって何入ってるのか知りたかった - Qiita 2018-11-19追記 https://github.com/CircleCI-Public/circleci-dockerfiles/blob/master/ruby/images/ いつの間にか公開されてました 動機 circleciが提供しているdockerファ... qiita.com CircleCI2.0のWorkflowsを試す “CircleCI2.0のWorkflowsを試す” is published by timakin. medium.com お知らせ メドレーでは、医療介護の求人サイト「 ジョブメドレー 」、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」、オンライン診療アプリ「 CLINICS 」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております。

こんにちは。開発本部の 稲本 です。医療介護の求人サイト「 ジョブメドレー 」の開発を担当しているエンジニアです。 最近ジョブメドレーでは CircleCI2.0 への移行を行いました。移行の方法はもちろん、その際に調べたこと、CircleCI の新機能を利用してどうだったかなどを書いていきたいと思います。 課題感 弊社では、全プロダクト( CLINICS 、 MEDLEY 、 介護のほんね 、 ジョブメドレー )で CircleCI を利用しています。 ジョブメドレーでは CI によるテスト実行に 37 分前後掛かっていました(コンテナを 2 つ利用した実行時間です)。 さらに、開発メンバーが増えて来たこともあり、CI のリソースが足りなくなり開発効率が落ちかねない状況でした。 まぁよくある話ですよね。 コンテナを増やすというのも解決策の一つとしてはあるのですが、速度の改善に期待が出来ると評判も良かったので CirclecCI2.0 へ移行しました。 CircleCI2.0 への移行メリット 基本的には速度の改善に期待が出来る、というのが大きなメリットではありますが、公式では以下のように記載されています。 抜粋ですが大きな特徴としては以下の点でしょうか。 First-class Docker Support: Docker のネイティブサポートと Docker レイヤーキャッシュの導入 Workflows: ビルド、テスト、デプロイをジョブとして柔軟に管理できるようになった Advanced Caching: キャッシュの保存とリストアをイメージ、ソースコード、依存関係に対して行うことができるようになった。 この辺りの機能を活用し CI の速度改善へ繋げてみたいと思います。 ジョブメドレーのアプリケーション構成 移行の前提として、ジョブメドレーのアプリケーション構成について記載します。 フロントエンドのビルドを yarn+webpack で行い、生成したアセットを public/assets へ吐き出し、manifest ファイルのパスを rails の helper 経由で取得し読み込んでいます。（Rails4.2.x） このような構成のアプリケーションを CirlceCI2.0 でビルド、テスト、デプロイ出来るようにしていきます。 config.yml の全体像 今回、作成した config.yml はこのような形になりました。 ざっくりは build: bundle install, yarn install code_analyze: rubocop, brakeman, scss-lint rspec deploy: capistrano を行っており、ブランチによってどのジョブを実行するのかを workflows を利用して使い分けています。 詳しい解説は以降、記載していきます。 defaults : & defaults working_directory : ~/job-medley docker : - image : circleci/ruby:2.4.2-node-browsers environment : TZ : /usr/share/zoneinfo/Asia/Tokyo - image : circleci/mysql:x.x.x environment : TZ : /usr/share/zoneinfo/Asia/Tokyo - image : redis:x.x.x environment : TZ : /usr/share/zoneinfo/Asia/Tokyo version : 2 jobs : build : << : * defaults steps : - checkout - restore_cache : key : job-medley-app-{{ checksum "Gemfile.lock" }} - run : name : bundle install command : bundle install --jobs=4 --path=vendor/bundle - save_cache : key : job-medley-app-{{ checksum "Gemfile.lock" }} paths : - vendor/bundle - restore_cache : key : job-medley-yarn-{{ checksum "yarn.lock" }} - run : name : Yarn install command : | echo "Node $(node -v)" echo "Yarn v$(yarn --version)" yarn config set cache-folder ./yarn_cache echo "Yarn v$(yarn cache dir)" yarn install - save_cache : key : job-medley-yarn-{{ checksum "yarn.lock" }} paths : - node_modules - yarn_cache - persist_to_workspace : root : ~/job-medley paths : - ./* code_analyze : << : * defaults steps : - attach_workspace : at : ~/job-medley - run : name : run rubocop command : bundle exec rubocop - run : name : run brakeman command : bundle exec brakeman -qz - run : name : run scss-lint command : bundle exec scss-lint rspec : parallelism : 2 << : * defaults steps : - attach_workspace : at : ~/job-medley - restore_cache : key : job-medley-elasticsearch # rspec で es のコマンドを一部実行しているため、primary container 側へ install - run : name : Elasticsearch install command : | wget https://download.elasticsearch.org/elasticsearch/elasticsearch/elasticsearch-x.x.x.tar.gz && \ tar -xvf elasticsearch-x.x.x.tar.gz && \ if [ -z "`elasticsearch-x.x.x/bin/plugin -l | grep analysis-kuromoji`" ]; then \ elasticsearch-x.x.x/bin/plugin -install elasticsearch/elasticsearch-analysis-kuromoji/x.x.x; fi - save_cache : key : job-medley-elasticsearch paths : - ./elasticsearch-x.x.x - run : name : database create command : bundle exec rake db:create environment : RAILS_ENV : test - run : name : run test command : | circleci tests glob 'spec/**/*_spec.*' \ | circleci tests split --split-by=timings --timings-type=filename \ | tee -a /dev/stderr \ | xargs bundle exec rspec \ --profile 100 \ --format RspecJunitFormatter \ --out rspec/rspec.xml \ --format progress environment : RAILS_ENV : test TEST_CLUSTER_COMMAND : elasticsearch-x.x.x/bin/elasticsearch - store_artifacts : path : artifacts/ - store_test_results : path : rspec/ deploy_qa : << : * defaults steps : - attach_workspace : at : ~/job-medley - run : name : run deploy command : | sh scripts/init_deploy.sh BRANCH="${CIRCLE_BRANCH}" bundle exec cap develop deploy deploy:restart deploy_only : << : * defaults steps : - attach_workspace : at : ~/job-medley - run : name : run deploy command : | BRANCH="${CIRCLE_BRANCH}" bundle exec cap production deploy deploy:restart workflows : version : 2 workflows : jobs : - build - code_analyze : requires : - build filters : branches : ignore : /^sandbox.*|^master$|^staging$/ - rspec : requires : - build filters : branches : ignore : /^sandbox.*|^master$|^staging$/ - deploy_qa : requires : - code_analyze - rspec filters : branches : only : develop - deploy_only : requires : - build filters : branches : only : /^sandbox.*|^master$|^staging$/ DockerImage の選定 元々、Docker を使わずに CI を回していましたが、CircleCI2.0 へ移行するに辺り Docker への利用に切り替えました。 ※ Specifying Container Images DockerImage は DockerHub へ登録されている CircleCI 公式のも の を利用しました。 アプリケーションの一部で React を使用しており、フロントのビルドは yarn+webpack を利用しています。その為、以下の image を選択しました。 circleci/ruby:2.4.2-node-browsers node のインストールと、E2E のテストに必要なソフトウェアがインストールされています。 ※詳細は こちらの記事 を参考にさせていただきました。 その他、現在利用している MySQL のバージョン、ElasticCacheRedis のバージョンと合わせた image を選択しました。 注意点としては、複数の DockerImage を利用する場合、一つ目に指定した image が primary として扱われます。 以下の例ですと、Ruby の image を最初に指定し、MySQL、Redis の image を指定していますが、MySQL コマンド自体は Ruby の image に含まれていないため、Ruby コマンドを実行できても MySQL コマンドを実行することは出来ません。 ※詳細は こちら に記載されています。 docker : - image : circleci/ruby:2.4.2-node-browsers environment : TZ : /usr/share/zoneinfo/Asia/Tokyo - image : circleci/mysql:x.x.x environment : TZ : /usr/share/zoneinfo/Asia/Tokyo - image : redis:x.x.x environment : TZ : /usr/share/zoneinfo/Asia/Tokyo また、用意されている image をカスタマイズする必要がある場合は、Docker でカスタム image を作り、public で良ければ Docker Hub へ登録、private が良ければ Amazon EC2 Container Registry へ登録しておくことで呼び出すことも可能になっています。 ※Using Custom-Built Docker Images https://circleci.com/docs/ja/2.0/custom-images/ ※Using Private Images https://circleci.com/docs/ja/2.0/private-images/ build の設定と cache CI で実行するアプリケーションの build に関してです。 checkout で github からコードを checkout し、その後の定義でアプリケーションのインストール、キャッシュ保存、キャッシュの展開を行っています。 steps : - checkout # Rails application setup - restore_cache : key : job-medley-app-{{ checksum "Gemfile.lock" }} - run : name : bundle install command : bundle install --jobs=4 --path=vendor/bundle - save_cache : key : job-medley-app-{{ checksum "Gemfile.lock" }} paths : - vendor/bundle save_cache: key に Gemfile.lock を指定することでキャッシュキーとして扱い、paths に設定したパスをキャッシュするようにしています。 restore_cache: key と一致するキャッシュがあれば、save_cache 時に指定したパスを展開し直しています。 run: こちらは rails のアプリケーションインストールしているだけです。 CircleCI1.0 よりもキャッシュ管理を柔軟に行えることがわかります。 circleci コマンドによる Rspec の並列実行 rspec によるテストの実行に関してです。 circleci コマンド を利用することでテストの並列実行を効率的に行うことが出来るます。 今回は --split-by=timings --timings-type=filename のオプションを指定し、ファイル名ベースでの分割でテストを実行します。 - run : name : run test command : | circleci tests glob 'spec/**/*_spec.*' \ | circleci tests split --split-by=timings --timings-type=filename \ | tee -a /dev/stderr \ | xargs bundle exec rspec \ --profile 100 \ --format RspecJunitFormatter \ --out rspec/rspec.xml \ --format progress environment : RAILS_ENV : test TEST_CLUSTER_COMMAND : elasticsearch-x.x.x/bin/elasticsearch - store_artifacts : path : artifacts/ - store_test_results : path : rspec/ store_artifacts: 以前からもある機能ですが、テスト結果の成果物を保存するパスになります。 store_test_results: こちらはテストの実行結果を保存しておくことで、コンテナ間で rspec の実行時間にばらつきが出ないよう、対象のファイルを最適に振り分けてくれるようなのですが、workflows を利用するとサポートされないようです。 ※参考： https://circleci.com/docs/ja/2.0/configuration-reference/#store_test_results このような形で Artifacts が保存されています。 また、artifacts には coverage と capybara の screenshot などを保存しています - simple_cov if ENV['CI'] SimpleCov.coverage_dir File.join(ENV['CIRCLE_WORKING_DIRECTORY'], 'artifacts', 'coverage') SimpleCov.formatter = SimpleCov::Formatter::MultiFormatter[ SimpleCov::Formatter::HTMLFormatter ] SimpleCov.start do add_filter '/vendor/' add_filter '/spec/' add_filter '/config/' add_filter '/db/' end end capybara Capybara.save_and_open_page_path = File.join(ENV['CIRCLE_WORKING_DIRECTORY'], 'artifacts', 'capybara') if ENV['CI'] ※CircleCI2.0 から CI の環境変数が変わっています。詳細は以下のリンクへ記載されています。 Introduction to environment variables - CircleCI Introduction to environment variables in CircleCI circleci.com Workflows の設定 CircleCI2.0 から Workflows の利用が可能になりました。 Workflow orchestration - CircleCI Learn about using CircleCI workflows to orchestrate jobs circleci.com コンテナ毎に分割しジョブを実行することで更なる並列実行の効率化、及び、ジョブ間の依存関係まで設定できるようです。 ジョブメドレーではコードの静的解析に少し実行時間が掛かっていることから、多少の改善を図れると考え 単純に使ってみたかった こちらの機能を利用してみました。 workflows : version : 2 workflows : jobs : - build - code_analyze : requires : - build filters : branches : ignore : /^sandbox.*|^master$|^staging$/ - rspec : requires : - build filters : branches : ignore : /^sandbox.*|^master$|^staging$/ - deploy_qa : requires : - code_analyze - rspec filters : branches : only : develop - deploy_only : requires : - build filters : branches : only : /^sandbox.*|^master$|^staging$/ build: 各ジョブで実行前に行っておく処理を定義 code_analyze: rubocop、brakeman、scss-lint などの静的解析処理を定義 rspec: アプリケーションのテストを定義 deploy: デプロイに関する処理を定義 ジョブメドレーでは、ブランチ管理に Git-flow を採用していますが、それとは別に sandbox というテスト環境を用意し運用しています。 develop ブランチでコード解析やテストをクリアしたコードだけ、master へ反映し、master ではテストフェーズなしに deploy する構成を取っています。 極力、CI のリソースを節約するように各ブランチごとで実行する処理を分けています。 各ブランチの運用は以下の通りです。 feature: コード解析、テスト実行 sandbox: デプロイのみ実行(一時レビュー用ブランチ) develop: コード解析、テスト実行、デプロイ実行 master: デプロイのみ実行 上記の例では、 code_analyze: sandbox、master、staging ブランチ以外は実行 requires で依存関係を指定し、build が正常に終了しなければ実行されないようになっています。 rspec: sandbox、master、staging ブランチ以外は実行 requires で依存関係を指定し、build が正常に終了しなければ実行されないようになっています。 deploy_qa: develop ブランチでのみ実行 requires で依存関係を指定し、code_analyze、rspec が正常に終了しなければ実行されないようになっています。 deploy_only: sandbox、master、staging ブランチのみ利用するジョブ requires で依存関係を指定し、build が正常に終了しなければ実行されないようになっています。 どのような workflow が出来あがるのか、以下に例を示します。 feature ブランチの例: develop ブランチの例: master、sandbox ブランチの例: 今回の例だとブランチ毎に workflow を変えているため、ignore、only の書き方で意図せず振り分けされないように考慮は必要ですが、柔軟に workflow を作れることがわかると思います。(やり過ぎると読み解くのが大変になりそうですね) Workflows に関しては こちら に色々なパターンの組み方が記載されているので、こちらを読むとより理解が深まると思います。 ジョブ間でのデータ共有 ジョブを分けてビルドする=何回もアプリケーションの初期化が必要なんじゃないか？ と当然疑問に思う点ではありますが、それに対する解決策も用意されています。 build : steps : ===省略=== - persist_to_workspace : root : ~/job-medley paths : - ./* deploy_qa : << : * defaults steps : - attach_workspace : at : ~/job-medley persist_to_workspace: 指定したパスにあるデータを一時的に保管してくれます attach_workspace: 保管済みのデータを展開してくれます この機能により、ビルドプロセスで生成したものを各ジョブで実行するコンテナへ渡すことが出来ます。 ただし、そもそもビルドプロセスでキャッシュを入れていることもあり、これ自体の効果は殆どありませんでした。 コンパイル済みのデータを受け渡す際には効果を発揮しそうですね。( 公式でも そのような利用を想定していそうです) 改善結果 肝心の速度改善結果です。結果は以下の通りになりました。 改善前: CircleCI1.0 rspec の実行時間: 26:59 以下は、CircleCI2.0 へ移行しただけの結果です。このケースでは workflows を利用していません。 改善後: CircleCI2.0 rspec の実行時間: 19:40 CircleCI1.0 から CircleCI2.0 へ移行することにより、 約 12 分程 テストの実行時間を短縮することが出来ました。 Workflows など特に利用していない、かつ、ビルドフェーズの実行時間も関係しないため、CircleCI2.0 を利用するだけで単純にテスト実行速度の向上を見込めることがわかると思います。 続いて Workflows を利用した結果です。 改善後: CircleCI2.0 with Workflows rspec の実行時間: 21:14 結果は、Workflows を利用しないケースと、利用したケースでは、Workflows を利用したほうが rspec の実行時間は長くなってしまいましたが、build-code-analyze-rspec の実行に掛かったトータルの時間に差は見られませんでした。 これは、「circleci コマンドによる Rspec の並列実行」のセクションへも記載した通り、store_test_results がサポートとされないことにより、コンテナ間での分散が最適化されていない為です。 コンテナ間で rspec の実行時間にばらつきが出ないよう、対象のファイルを最適に振り分けてくれるようなのですが、Workflows を利用するとサポートされないようです。 実行時間にばらつきが出てしまい、code_analyze のジョブを分散することで見込んでいた改善時間(約 3 分)とばらつきにより発生したテスト実行時間のロス( (20:01 - 14:57) / 2 = 2:32 )が大体同じであるため、トータルでの実行時間に差が出ない結果となりました。 ばらつきを出さない方法や、ジョブの分け方については今後も工夫してみたいと思います。 また、フロントエンドのテストをもう少し厚くしていきたいと考えているので、フロントエンドのテスト、サーバサイドのテストを Workflows を上手く使いながら分散していければ良いのかなとも思っています。 さいごに 移行に際して、 CircleCI2.0 の移行ガイド を読みながら進めていましたが、基本的な記法の変更、timezone、environment の定義方法の変更、variable の変更などが多々有り、ドキュメントを結構読み込まないとどこに何が定義できるのか把握できませんでした。 また、Workflows の組み立てなど 公式に良いサンプル は沢山あるのですが、依存関係の定義を色々試すのに苦労した気がします。 ※素直に小規模なアプリを用意して、 ローカルで circleci を実行 してみた方が効率良く進められたかもしれません。 ※ただ、 公式のドキュメント や CommunityForum をしっかり読めば余すことなく情報は合ったので非常に助かりました。 CircleCI2.0 でどのような事が出来るのか、それはどのように行えるのか。 この記事がその概観をつかむ助けになれば良いなと思っています。 参考リンク CircleCI2.0 へ移行するにあたり、以下の記事を参考にさせていただきました。ありがとうございます。 circleci/ruby:2.4.1-node-browsersって何入ってるのか知りたかった - Qiita 2018-11-19追記 https://github.com/CircleCI-Public/circleci-dockerfiles/blob/master/ruby/images/ いつの間にか公開されてました 動機 circleciが提供しているdockerファ... qiita.com CircleCI2.0のWorkflowsを試す “CircleCI2.0のWorkflowsを試す” is published by timakin. medium.com お知らせ メドレーでは、医療介護の求人サイト「 ジョブメドレー 」、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」、オンライン診療アプリ「 CLINICS 」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております。

こんにちは。開発本部の 稲本 です。医療介護の求人サイト「 ジョブメドレー 」の開発を担当しているエンジニアです。 最近ジョブメドレーでは CircleCI2.0 への移行を行いました。移行の方法はもちろん、その際に調べたこと、CircleCI の新機能を利用してどうだったかなどを書いていきたいと思います。 課題感 弊社では、全プロダクト( CLINICS 、 MEDLEY 、 介護のほんね 、 ジョブメドレー )で CircleCI を利用しています。 ジョブメドレーでは CI によるテスト実行に 37 分前後掛かっていました(コンテナを 2 つ利用した実行時間です)。 さらに、開発メンバーが増えて来たこともあり、CI のリソースが足りなくなり開発効率が落ちかねない状況でした。 まぁよくある話ですよね。 コンテナを増やすというのも解決策の一つとしてはあるのですが、速度の改善に期待が出来ると評判も良かったので CirclecCI2.0 へ移行しました。 CircleCI2.0 への移行メリット 基本的には速度の改善に期待が出来る、というのが大きなメリットではありますが、公式では以下のように記載されています。 抜粋ですが大きな特徴としては以下の点でしょうか。 First-class Docker Support: Docker のネイティブサポートと Docker レイヤーキャッシュの導入 Workflows: ビルド、テスト、デプロイをジョブとして柔軟に管理できるようになった Advanced Caching: キャッシュの保存とリストアをイメージ、ソースコード、依存関係に対して行うことができるようになった。 この辺りの機能を活用し CI の速度改善へ繋げてみたいと思います。 ジョブメドレーのアプリケーション構成 移行の前提として、ジョブメドレーのアプリケーション構成について記載します。 フロントエンドのビルドを yarn+webpack で行い、生成したアセットを public/assets へ吐き出し、manifest ファイルのパスを rails の helper 経由で取得し読み込んでいます。（Rails4.2.x） このような構成のアプリケーションを CirlceCI2.0 でビルド、テスト、デプロイ出来るようにしていきます。 config.yml の全体像 今回、作成した config.yml はこのような形になりました。 ざっくりは build: bundle install, yarn install code_analyze: rubocop, brakeman, scss-lint rspec deploy: capistrano を行っており、ブランチによってどのジョブを実行するのかを workflows を利用して使い分けています。 詳しい解説は以降、記載していきます。 defaults : & defaults working_directory : ~/job-medley docker : - image : circleci/ruby:2.4.2-node-browsers environment : TZ : /usr/share/zoneinfo/Asia/Tokyo - image : circleci/mysql:x.x.x environment : TZ : /usr/share/zoneinfo/Asia/Tokyo - image : redis:x.x.x environment : TZ : /usr/share/zoneinfo/Asia/Tokyo version : 2 jobs : build : << : * defaults steps : - checkout - restore_cache : key : job-medley-app-{{ checksum "Gemfile.lock" }} - run : name : bundle install command : bundle install --jobs=4 --path=vendor/bundle - save_cache : key : job-medley-app-{{ checksum "Gemfile.lock" }} paths : - vendor/bundle - restore_cache : key : job-medley-yarn-{{ checksum "yarn.lock" }} - run : name : Yarn install command : | echo "Node $(node -v)" echo "Yarn v$(yarn --version)" yarn config set cache-folder ./yarn_cache echo "Yarn v$(yarn cache dir)" yarn install - save_cache : key : job-medley-yarn-{{ checksum "yarn.lock" }} paths : - node_modules - yarn_cache - persist_to_workspace : root : ~/job-medley paths : - ./* code_analyze : << : * defaults steps : - attach_workspace : at : ~/job-medley - run : name : run rubocop command : bundle exec rubocop - run : name : run brakeman command : bundle exec brakeman -qz - run : name : run scss-lint command : bundle exec scss-lint rspec : parallelism : 2 << : * defaults steps : - attach_workspace : at : ~/job-medley - restore_cache : key : job-medley-elasticsearch # rspec で es のコマンドを一部実行しているため、primary container 側へ install - run : name : Elasticsearch install command : | wget https://download.elasticsearch.org/elasticsearch/elasticsearch/elasticsearch-x.x.x.tar.gz && \ tar -xvf elasticsearch-x.x.x.tar.gz && \ if [ -z "`elasticsearch-x.x.x/bin/plugin -l | grep analysis-kuromoji`" ]; then \ elasticsearch-x.x.x/bin/plugin -install elasticsearch/elasticsearch-analysis-kuromoji/x.x.x; fi - save_cache : key : job-medley-elasticsearch paths : - ./elasticsearch-x.x.x - run : name : database create command : bundle exec rake db:create environment : RAILS_ENV : test - run : name : run test command : | circleci tests glob 'spec/**/*_spec.*' \ | circleci tests split --split-by=timings --timings-type=filename \ | tee -a /dev/stderr \ | xargs bundle exec rspec \ --profile 100 \ --format RspecJunitFormatter \ --out rspec/rspec.xml \ --format progress environment : RAILS_ENV : test TEST_CLUSTER_COMMAND : elasticsearch-x.x.x/bin/elasticsearch - store_artifacts : path : artifacts/ - store_test_results : path : rspec/ deploy_qa : << : * defaults steps : - attach_workspace : at : ~/job-medley - run : name : run deploy command : | sh scripts/init_deploy.sh BRANCH="${CIRCLE_BRANCH}" bundle exec cap develop deploy deploy:restart deploy_only : << : * defaults steps : - attach_workspace : at : ~/job-medley - run : name : run deploy command : | BRANCH="${CIRCLE_BRANCH}" bundle exec cap production deploy deploy:restart workflows : version : 2 workflows : jobs : - build - code_analyze : requires : - build filters : branches : ignore : /^sandbox.*|^master$|^staging$/ - rspec : requires : - build filters : branches : ignore : /^sandbox.*|^master$|^staging$/ - deploy_qa : requires : - code_analyze - rspec filters : branches : only : develop - deploy_only : requires : - build filters : branches : only : /^sandbox.*|^master$|^staging$/ DockerImage の選定 元々、Docker を使わずに CI を回していましたが、CircleCI2.0 へ移行するに辺り Docker への利用に切り替えました。 ※ Specifying Container Images DockerImage は DockerHub へ登録されている CircleCI 公式のも の を利用しました。 アプリケーションの一部で React を使用しており、フロントのビルドは yarn+webpack を利用しています。その為、以下の image を選択しました。 circleci/ruby:2.4.2-node-browsers node のインストールと、E2E のテストに必要なソフトウェアがインストールされています。 ※詳細は こちらの記事 を参考にさせていただきました。 その他、現在利用している MySQL のバージョン、ElasticCacheRedis のバージョンと合わせた image を選択しました。 注意点としては、複数の DockerImage を利用する場合、一つ目に指定した image が primary として扱われます。 以下の例ですと、Ruby の image を最初に指定し、MySQL、Redis の image を指定していますが、MySQL コマンド自体は Ruby の image に含まれていないため、Ruby コマンドを実行できても MySQL コマンドを実行することは出来ません。 ※詳細は こちら に記載されています。 docker : - image : circleci/ruby:2.4.2-node-browsers environment : TZ : /usr/share/zoneinfo/Asia/Tokyo - image : circleci/mysql:x.x.x environment : TZ : /usr/share/zoneinfo/Asia/Tokyo - image : redis:x.x.x environment : TZ : /usr/share/zoneinfo/Asia/Tokyo また、用意されている image をカスタマイズする必要がある場合は、Docker でカスタム image を作り、public で良ければ Docker Hub へ登録、private が良ければ Amazon EC2 Container Registry へ登録しておくことで呼び出すことも可能になっています。 ※Using Custom-Built Docker Images https://circleci.com/docs/ja/2.0/custom-images/ ※Using Private Images https://circleci.com/docs/ja/2.0/private-images/ build の設定と cache CI で実行するアプリケーションの build に関してです。 checkout で github からコードを checkout し、その後の定義でアプリケーションのインストール、キャッシュ保存、キャッシュの展開を行っています。 steps : - checkout # Rails application setup - restore_cache : key : job-medley-app-{{ checksum "Gemfile.lock" }} - run : name : bundle install command : bundle install --jobs=4 --path=vendor/bundle - save_cache : key : job-medley-app-{{ checksum "Gemfile.lock" }} paths : - vendor/bundle save_cache: key に Gemfile.lock を指定することでキャッシュキーとして扱い、paths に設定したパスをキャッシュするようにしています。 restore_cache: key と一致するキャッシュがあれば、save_cache 時に指定したパスを展開し直しています。 run: こちらは rails のアプリケーションインストールしているだけです。 CircleCI1.0 よりもキャッシュ管理を柔軟に行えることがわかります。 circleci コマンドによる Rspec の並列実行 rspec によるテストの実行に関してです。 circleci コマンド を利用することでテストの並列実行を効率的に行うことが出来るます。 今回は --split-by=timings --timings-type=filename のオプションを指定し、ファイル名ベースでの分割でテストを実行します。 - run : name : run test command : | circleci tests glob 'spec/**/*_spec.*' \ | circleci tests split --split-by=timings --timings-type=filename \ | tee -a /dev/stderr \ | xargs bundle exec rspec \ --profile 100 \ --format RspecJunitFormatter \ --out rspec/rspec.xml \ --format progress environment : RAILS_ENV : test TEST_CLUSTER_COMMAND : elasticsearch-x.x.x/bin/elasticsearch - store_artifacts : path : artifacts/ - store_test_results : path : rspec/ store_artifacts: 以前からもある機能ですが、テスト結果の成果物を保存するパスになります。 store_test_results: こちらはテストの実行結果を保存しておくことで、コンテナ間で rspec の実行時間にばらつきが出ないよう、対象のファイルを最適に振り分けてくれるようなのですが、workflows を利用するとサポートされないようです。 ※参考： https://circleci.com/docs/ja/2.0/configuration-reference/#store_test_results このような形で Artifacts が保存されています。 また、artifacts には coverage と capybara の screenshot などを保存しています - simple_cov if ENV['CI'] SimpleCov.coverage_dir File.join(ENV['CIRCLE_WORKING_DIRECTORY'], 'artifacts', 'coverage') SimpleCov.formatter = SimpleCov::Formatter::MultiFormatter[ SimpleCov::Formatter::HTMLFormatter ] SimpleCov.start do add_filter '/vendor/' add_filter '/spec/' add_filter '/config/' add_filter '/db/' end end capybara Capybara.save_and_open_page_path = File.join(ENV['CIRCLE_WORKING_DIRECTORY'], 'artifacts', 'capybara') if ENV['CI'] ※CircleCI2.0 から CI の環境変数が変わっています。詳細は以下のリンクへ記載されています。 Introduction to environment variables - CircleCI Introduction to environment variables in CircleCI circleci.com Workflows の設定 CircleCI2.0 から Workflows の利用が可能になりました。 Workflow orchestration - CircleCI Learn about using CircleCI workflows to orchestrate jobs circleci.com コンテナ毎に分割しジョブを実行することで更なる並列実行の効率化、及び、ジョブ間の依存関係まで設定できるようです。 ジョブメドレーではコードの静的解析に少し実行時間が掛かっていることから、多少の改善を図れると考え 単純に使ってみたかった こちらの機能を利用してみました。 workflows : version : 2 workflows : jobs : - build - code_analyze : requires : - build filters : branches : ignore : /^sandbox.*|^master$|^staging$/ - rspec : requires : - build filters : branches : ignore : /^sandbox.*|^master$|^staging$/ - deploy_qa : requires : - code_analyze - rspec filters : branches : only : develop - deploy_only : requires : - build filters : branches : only : /^sandbox.*|^master$|^staging$/ build: 各ジョブで実行前に行っておく処理を定義 code_analyze: rubocop、brakeman、scss-lint などの静的解析処理を定義 rspec: アプリケーションのテストを定義 deploy: デプロイに関する処理を定義 ジョブメドレーでは、ブランチ管理に Git-flow を採用していますが、それとは別に sandbox というテスト環境を用意し運用しています。 develop ブランチでコード解析やテストをクリアしたコードだけ、master へ反映し、master ではテストフェーズなしに deploy する構成を取っています。 極力、CI のリソースを節約するように各ブランチごとで実行する処理を分けています。 各ブランチの運用は以下の通りです。 feature: コード解析、テスト実行 sandbox: デプロイのみ実行(一時レビュー用ブランチ) develop: コード解析、テスト実行、デプロイ実行 master: デプロイのみ実行 上記の例では、 code_analyze: sandbox、master、staging ブランチ以外は実行 requires で依存関係を指定し、build が正常に終了しなければ実行されないようになっています。 rspec: sandbox、master、staging ブランチ以外は実行 requires で依存関係を指定し、build が正常に終了しなければ実行されないようになっています。 deploy_qa: develop ブランチでのみ実行 requires で依存関係を指定し、code_analyze、rspec が正常に終了しなければ実行されないようになっています。 deploy_only: sandbox、master、staging ブランチのみ利用するジョブ requires で依存関係を指定し、build が正常に終了しなければ実行されないようになっています。 どのような workflow が出来あがるのか、以下に例を示します。 feature ブランチの例: develop ブランチの例: master、sandbox ブランチの例: 今回の例だとブランチ毎に workflow を変えているため、ignore、only の書き方で意図せず振り分けされないように考慮は必要ですが、柔軟に workflow を作れることがわかると思います。(やり過ぎると読み解くのが大変になりそうですね) Workflows に関しては こちら に色々なパターンの組み方が記載されているので、こちらを読むとより理解が深まると思います。 ジョブ間でのデータ共有 ジョブを分けてビルドする=何回もアプリケーションの初期化が必要なんじゃないか？ と当然疑問に思う点ではありますが、それに対する解決策も用意されています。 build : steps : ===省略=== - persist_to_workspace : root : ~/job-medley paths : - ./* deploy_qa : << : * defaults steps : - attach_workspace : at : ~/job-medley persist_to_workspace: 指定したパスにあるデータを一時的に保管してくれます attach_workspace: 保管済みのデータを展開してくれます この機能により、ビルドプロセスで生成したものを各ジョブで実行するコンテナへ渡すことが出来ます。 ただし、そもそもビルドプロセスでキャッシュを入れていることもあり、これ自体の効果は殆どありませんでした。 コンパイル済みのデータを受け渡す際には効果を発揮しそうですね。( 公式でも そのような利用を想定していそうです) 改善結果 肝心の速度改善結果です。結果は以下の通りになりました。 改善前: CircleCI1.0 rspec の実行時間: 26:59 以下は、CircleCI2.0 へ移行しただけの結果です。このケースでは workflows を利用していません。 改善後: CircleCI2.0 rspec の実行時間: 19:40 CircleCI1.0 から CircleCI2.0 へ移行することにより、 約 12 分程 テストの実行時間を短縮することが出来ました。 Workflows など特に利用していない、かつ、ビルドフェーズの実行時間も関係しないため、CircleCI2.0 を利用するだけで単純にテスト実行速度の向上を見込めることがわかると思います。 続いて Workflows を利用した結果です。 改善後: CircleCI2.0 with Workflows rspec の実行時間: 21:14 結果は、Workflows を利用しないケースと、利用したケースでは、Workflows を利用したほうが rspec の実行時間は長くなってしまいましたが、build-code-analyze-rspec の実行に掛かったトータルの時間に差は見られませんでした。 これは、「circleci コマンドによる Rspec の並列実行」のセクションへも記載した通り、store_test_results がサポートとされないことにより、コンテナ間での分散が最適化されていない為です。 コンテナ間で rspec の実行時間にばらつきが出ないよう、対象のファイルを最適に振り分けてくれるようなのですが、Workflows を利用するとサポートされないようです。 実行時間にばらつきが出てしまい、code_analyze のジョブを分散することで見込んでいた改善時間(約 3 分)とばらつきにより発生したテスト実行時間のロス( (20:01 - 14:57) / 2 = 2:32 )が大体同じであるため、トータルでの実行時間に差が出ない結果となりました。 ばらつきを出さない方法や、ジョブの分け方については今後も工夫してみたいと思います。 また、フロントエンドのテストをもう少し厚くしていきたいと考えているので、フロントエンドのテスト、サーバサイドのテストを Workflows を上手く使いながら分散していければ良いのかなとも思っています。 さいごに 移行に際して、 CircleCI2.0 の移行ガイド を読みながら進めていましたが、基本的な記法の変更、timezone、environment の定義方法の変更、variable の変更などが多々有り、ドキュメントを結構読み込まないとどこに何が定義できるのか把握できませんでした。 また、Workflows の組み立てなど 公式に良いサンプル は沢山あるのですが、依存関係の定義を色々試すのに苦労した気がします。 ※素直に小規模なアプリを用意して、 ローカルで circleci を実行 してみた方が効率良く進められたかもしれません。 ※ただ、 公式のドキュメント や CommunityForum をしっかり読めば余すことなく情報は合ったので非常に助かりました。 CircleCI2.0 でどのような事が出来るのか、それはどのように行えるのか。 この記事がその概観をつかむ助けになれば良いなと思っています。 参考リンク CircleCI2.0 へ移行するにあたり、以下の記事を参考にさせていただきました。ありがとうございます。 circleci/ruby:2.4.1-node-browsersって何入ってるのか知りたかった - Qiita 2018-11-19追記 https://github.com/CircleCI-Public/circleci-dockerfiles/blob/master/ruby/images/ いつの間にか公開されてました 動機 circleciが提供しているdockerファ... qiita.com CircleCI2.0のWorkflowsを試す “CircleCI2.0のWorkflowsを試す” is published by timakin. medium.com お知らせ メドレーでは、医療介護の求人サイト「 ジョブメドレー 」、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」、オンライン診療アプリ「 CLINICS 」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております。

ジョブメドレーの開発運用を担当している 新居 です。 メドレーでは開発本部のメンバーの技術力底上げや課題解決を目的とした短期プロジェクト（タスクフォースと呼んでいます）を実施しています。この取り組みの一環として、6〜8 月はセキュリティ知識の底上げを目指した「セキュリティタスクフォース」を実施しました。今回は、その取り組み内容を紹介します。 背景 現在、メドレーの開発本部には約 20 名のエンジニアが在籍しており、それぞれ多種多様な開発経験やスキルセットを持ったエンジニアが集まっています。 そして、前職ではフロントエンド専門でやってきたエンジニアもサーバーサイドの開発を行ったり、またその逆のケースもあったりと、各自の専門領域にとらわれないスタイルでの開発を行うことも多々あります。 課題 そういった背景の中、エンジニアが増えていくにつれエンジニア間のスキルセットに差が生まれ、ばらつきが見られるようにもなっています。今後、更に組織が拡大していくのに伴い、こうしたエンジニア間のスキルセットの差も大きくなっていくことが懸念されます。 また、メドレーは医療ヘルスケア分野に向けてサービス提供を行っており、多くの個人情報を扱っていることはもちろん、医療・介護という領域の性質上、セキュリティには非常に気をつかう必要があります。データベースに入れて保守・運用している個人情報などの取り扱いや、システム改善や新機能開発などを行うときには必然的にセキュリティにも配慮して開発を進める必要があります。 そして背景のところでも述べたように、元々フロントエンド専門のエンジニアがサーバーサイドの開発に関わるケースや、そもそもサーバーサイド開発の経験が浅いエンジニアも中にはいて、サーバーサイドのセキュリティに関して自信がなかったり、具体的な対策方法がすぐに出てこないこともあるという課題がありました（当然ですが実際の開発では PR などでレビューして問題が起きないように対応しています）。 そこで、そういったメンバーのセキュリティ知識の底上げを行い、エンジニア間のスキルセットの差を縮めていくことが必要であると考えました。 取り組み 上述した通り、 スキルセットにばらつきや差が見られる 医療ヘルスケア分野は特にセキュリティに気を使う必要がある セキュリティに関して自信がない、具体的な対策方法がすぐに出てこないこともある といった課題感から、まずはフロントエンド専門でやってきたメンバーやサーバーサイド開発の経験が浅いメンバーをメインターゲットとして、セキュリティ知識の底上げをやっていくことにフォーカスしました。 目標としては、ウェブアプリケーション開発における最低限のセキュリティ知識や対策方法をしっかり再整理し、さらに開発で使っている Ruby on Rails 上でどのように対策するべきかを押さえるというところを目標におきました。 形式 形式としては、参加者に事前に教材の対象範囲を読んできてもらい、隔週開催の TechLunch（社内勉強会）終了後の約 20 分を利用して、内容の簡単な説明や補足、質疑応答、議論などを行う場（フォロー会）を設けました。 教材 以下を使用しました。 メイン教材：「IPA の安全なウェブサイトの作り方」 www.ipa.go.jp サブ教材：「Rails セキュリティガイド」 railsguides.jp メイン教材の「IPA の安全なウェブサイトの作り方」は、IPA が届出を受けた脆弱性関連情報を基にして作られており、セキュリティを考慮したウェブサイトを作る上での最低限の知識が整理できるだろうということで採用しました。 サブ教材の「Rails セキュリティガイド」は、Rails ではどのようにセキュリティの問題を回避しているのかといった方法が解説されており、実際の開発のときにどうすれば良いのかといったことが押さえられるだろうということで採用しました。 実際の開催スケジュールと、フォロー会の対象範囲はこちら。 取り組みを終えて 取り組みを終えて感じたこととしては以下になります。 技術的な観点 SQL インジェクションや XSS、CSRF などのメジャーな攻撃手法を参加者間で再整理できた 技術的に不安なところなどは「ここはこうですよね？」という感じで確かめ合うことができた 参加者が前職での経験談などをシェアしてくれる場面もあり、知見の共有ができた セキュリティに詳しいエンジニアも交えて話すことで、随所で効果的にツッコミをいただき、濃密な議論ができた ベテランエンジニアからは、昔流行った某サービスの某セキュリティ系障害の有名事例なども共有され、過去の歴史を知ることができる場となった 技術以外の観点 普段はチーム毎に黙々と仕事に取り組んでおり、チームを跨いであるひとつの話題（今回はセキュリティ）についてみんなと会話する機会は少ないので、知識の底上げはもちろんのこと、コミュニケーションの場としても良かった 今回のように質疑応答や議論ができる場を設けることにより、他のメンバーの経験や知見も効果的に共有することができ、教材の読み合わせや講義形式では得られない知識も共有でき、取り組みとしてはうまくいったかなあと思います。 まとめ ということで、今回はセキュリティタスクフォースについてご紹介しました。 セキュリティの知識はだれかひとりが押さえていれば良いというものではなく、開発に関わるエンジニア全員が最低限は押さえておく必要があると思います。 組織の拡大と共に、日々のプロダクトの運用・開発も大切ですが、それらを支えるエンジニアの知識の底上げなどの開発以外の部分もより大切になってきますし、そういった取り組みが組織力を高めていくのではないかと思います。 お知らせ メドレーでは、医療介護の求人サイト「 ジョブメドレー 」、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる 介護施設 の検索サイト「 介護のほんね 」、オンライン診療アプリ「 CLINICS 」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 www.medley.jp 医療や介護とは全く違う業界で経験を積んできたエンジニア・デザイナーが多いですが、こうした定期的な勉強会などで必要知識をインプットしながら開発しています。 メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております！

ジョブメドレーの開発運用を担当している 新居 です。 メドレーでは開発本部のメンバーの技術力底上げや課題解決を目的とした短期プロジェクト（タスクフォースと呼んでいます）を実施しています。この取り組みの一環として、6〜8 月はセキュリティ知識の底上げを目指した「セキュリティタスクフォース」を実施しました。今回は、その取り組み内容を紹介します。 背景 現在、メドレーの開発本部には約 20 名のエンジニアが在籍しており、それぞれ多種多様な開発経験やスキルセットを持ったエンジニアが集まっています。 そして、前職ではフロントエンド専門でやってきたエンジニアもサーバーサイドの開発を行ったり、またその逆のケースもあったりと、各自の専門領域にとらわれないスタイルでの開発を行うことも多々あります。 課題 そういった背景の中、エンジニアが増えていくにつれエンジニア間のスキルセットに差が生まれ、ばらつきが見られるようにもなっています。今後、更に組織が拡大していくのに伴い、こうしたエンジニア間のスキルセットの差も大きくなっていくことが懸念されます。 また、メドレーは医療ヘルスケア分野に向けてサービス提供を行っており、多くの個人情報を扱っていることはもちろん、医療・介護という領域の性質上、セキュリティには非常に気をつかう必要があります。データベースに入れて保守・運用している個人情報などの取り扱いや、システム改善や新機能開発などを行うときには必然的にセキュリティにも配慮して開発を進める必要があります。 そして背景のところでも述べたように、元々フロントエンド専門のエンジニアがサーバーサイドの開発に関わるケースや、そもそもサーバーサイド開発の経験が浅いエンジニアも中にはいて、サーバーサイドのセキュリティに関して自信がなかったり、具体的な対策方法がすぐに出てこないこともあるという課題がありました（当然ですが実際の開発では PR などでレビューして問題が起きないように対応しています）。 そこで、そういったメンバーのセキュリティ知識の底上げを行い、エンジニア間のスキルセットの差を縮めていくことが必要であると考えました。 取り組み 上述した通り、 スキルセットにばらつきや差が見られる 医療ヘルスケア分野は特にセキュリティに気を使う必要がある セキュリティに関して自信がない、具体的な対策方法がすぐに出てこないこともある といった課題感から、まずはフロントエンド専門でやってきたメンバーやサーバーサイド開発の経験が浅いメンバーをメインターゲットとして、セキュリティ知識の底上げをやっていくことにフォーカスしました。 目標としては、ウェブアプリケーション開発における最低限のセキュリティ知識や対策方法をしっかり再整理し、さらに開発で使っている Ruby on Rails 上でどのように対策するべきかを押さえるというところを目標におきました。 形式 形式としては、参加者に事前に教材の対象範囲を読んできてもらい、隔週開催の TechLunch（社内勉強会）終了後の約 20 分を利用して、内容の簡単な説明や補足、質疑応答、議論などを行う場（フォロー会）を設けました。 教材 以下を使用しました。 メイン教材：「IPA の安全なウェブサイトの作り方」 www.ipa.go.jp サブ教材：「Rails セキュリティガイド」 railsguides.jp メイン教材の「IPA の安全なウェブサイトの作り方」は、IPA が届出を受けた脆弱性関連情報を基にして作られており、セキュリティを考慮したウェブサイトを作る上での最低限の知識が整理できるだろうということで採用しました。 サブ教材の「Rails セキュリティガイド」は、Rails ではどのようにセキュリティの問題を回避しているのかといった方法が解説されており、実際の開発のときにどうすれば良いのかといったことが押さえられるだろうということで採用しました。 実際の開催スケジュールと、フォロー会の対象範囲はこちら。 取り組みを終えて 取り組みを終えて感じたこととしては以下になります。 技術的な観点 SQL インジェクションや XSS、CSRF などのメジャーな攻撃手法を参加者間で再整理できた 技術的に不安なところなどは「ここはこうですよね？」という感じで確かめ合うことができた 参加者が前職での経験談などをシェアしてくれる場面もあり、知見の共有ができた セキュリティに詳しいエンジニアも交えて話すことで、随所で効果的にツッコミをいただき、濃密な議論ができた ベテランエンジニアからは、昔流行った某サービスの某セキュリティ系障害の有名事例なども共有され、過去の歴史を知ることができる場となった 技術以外の観点 普段はチーム毎に黙々と仕事に取り組んでおり、チームを跨いであるひとつの話題（今回はセキュリティ）についてみんなと会話する機会は少ないので、知識の底上げはもちろんのこと、コミュニケーションの場としても良かった 今回のように質疑応答や議論ができる場を設けることにより、他のメンバーの経験や知見も効果的に共有することができ、教材の読み合わせや講義形式では得られない知識も共有でき、取り組みとしてはうまくいったかなあと思います。 まとめ ということで、今回はセキュリティタスクフォースについてご紹介しました。 セキュリティの知識はだれかひとりが押さえていれば良いというものではなく、開発に関わるエンジニア全員が最低限は押さえておく必要があると思います。 組織の拡大と共に、日々のプロダクトの運用・開発も大切ですが、それらを支えるエンジニアの知識の底上げなどの開発以外の部分もより大切になってきますし、そういった取り組みが組織力を高めていくのではないかと思います。 お知らせ メドレーでは、医療介護の求人サイト「 ジョブメドレー 」、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる 介護施設 の検索サイト「 介護のほんね 」、オンライン診療アプリ「 CLINICS 」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 www.medley.jp 医療や介護とは全く違う業界で経験を積んできたエンジニア・デザイナーが多いですが、こうした定期的な勉強会などで必要知識をインプットしながら開発しています。 メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております！

ジョブメドレーの開発運用を担当している 新居 です。 メドレーでは開発本部のメンバーの技術力底上げや課題解決を目的とした短期プロジェクト（タスクフォースと呼んでいます）を実施しています。この取り組みの一環として、6〜8 月はセキュリティ知識の底上げを目指した「セキュリティタスクフォース」を実施しました。今回は、その取り組み内容を紹介します。 背景 現在、メドレーの開発本部には約 20 名のエンジニアが在籍しており、それぞれ多種多様な開発経験やスキルセットを持ったエンジニアが集まっています。 そして、前職ではフロントエンド専門でやってきたエンジニアもサーバーサイドの開発を行ったり、またその逆のケースもあったりと、各自の専門領域にとらわれないスタイルでの開発を行うことも多々あります。 課題 そういった背景の中、エンジニアが増えていくにつれエンジニア間のスキルセットに差が生まれ、ばらつきが見られるようにもなっています。今後、更に組織が拡大していくのに伴い、こうしたエンジニア間のスキルセットの差も大きくなっていくことが懸念されます。 また、メドレーは医療ヘルスケア分野に向けてサービス提供を行っており、多くの個人情報を扱っていることはもちろん、医療・介護という領域の性質上、セキュリティには非常に気をつかう必要があります。データベースに入れて保守・運用している個人情報などの取り扱いや、システム改善や新機能開発などを行うときには必然的にセキュリティにも配慮して開発を進める必要があります。 そして背景のところでも述べたように、元々フロントエンド専門のエンジニアがサーバーサイドの開発に関わるケースや、そもそもサーバーサイド開発の経験が浅いエンジニアも中にはいて、サーバーサイドのセキュリティに関して自信がなかったり、具体的な対策方法がすぐに出てこないこともあるという課題がありました（当然ですが実際の開発では PR などでレビューして問題が起きないように対応しています）。 そこで、そういったメンバーのセキュリティ知識の底上げを行い、エンジニア間のスキルセットの差を縮めていくことが必要であると考えました。 取り組み 上述した通り、 スキルセットにばらつきや差が見られる 医療ヘルスケア分野は特にセキュリティに気を使う必要がある セキュリティに関して自信がない、具体的な対策方法がすぐに出てこないこともある といった課題感から、まずはフロントエンド専門でやってきたメンバーやサーバーサイド開発の経験が浅いメンバーをメインターゲットとして、セキュリティ知識の底上げをやっていくことにフォーカスしました。 目標としては、ウェブアプリケーション開発における最低限のセキュリティ知識や対策方法をしっかり再整理し、さらに開発で使っている Ruby on Rails 上でどのように対策するべきかを押さえるというところを目標におきました。 形式 形式としては、参加者に事前に教材の対象範囲を読んできてもらい、隔週開催の TechLunch（社内勉強会）終了後の約 20 分を利用して、内容の簡単な説明や補足、質疑応答、議論などを行う場（フォロー会）を設けました。 教材 以下を使用しました。 メイン教材：「IPA の安全なウェブサイトの作り方」 www.ipa.go.jp サブ教材：「Rails セキュリティガイド」 railsguides.jp メイン教材の「IPA の安全なウェブサイトの作り方」は、IPA が届出を受けた脆弱性関連情報を基にして作られており、セキュリティを考慮したウェブサイトを作る上での最低限の知識が整理できるだろうということで採用しました。 サブ教材の「Rails セキュリティガイド」は、Rails ではどのようにセキュリティの問題を回避しているのかといった方法が解説されており、実際の開発のときにどうすれば良いのかといったことが押さえられるだろうということで採用しました。 実際の開催スケジュールと、フォロー会の対象範囲はこちら。 取り組みを終えて 取り組みを終えて感じたこととしては以下になります。 技術的な観点 SQL インジェクションや XSS、CSRF などのメジャーな攻撃手法を参加者間で再整理できた 技術的に不安なところなどは「ここはこうですよね？」という感じで確かめ合うことができた 参加者が前職での経験談などをシェアしてくれる場面もあり、知見の共有ができた セキュリティに詳しいエンジニアも交えて話すことで、随所で効果的にツッコミをいただき、濃密な議論ができた ベテランエンジニアからは、昔流行った某サービスの某セキュリティ系障害の有名事例なども共有され、過去の歴史を知ることができる場となった 技術以外の観点 普段はチーム毎に黙々と仕事に取り組んでおり、チームを跨いであるひとつの話題（今回はセキュリティ）についてみんなと会話する機会は少ないので、知識の底上げはもちろんのこと、コミュニケーションの場としても良かった 今回のように質疑応答や議論ができる場を設けることにより、他のメンバーの経験や知見も効果的に共有することができ、教材の読み合わせや講義形式では得られない知識も共有でき、取り組みとしてはうまくいったかなあと思います。 まとめ ということで、今回はセキュリティタスクフォースについてご紹介しました。 セキュリティの知識はだれかひとりが押さえていれば良いというものではなく、開発に関わるエンジニア全員が最低限は押さえておく必要があると思います。 組織の拡大と共に、日々のプロダクトの運用・開発も大切ですが、それらを支えるエンジニアの知識の底上げなどの開発以外の部分もより大切になってきますし、そういった取り組みが組織力を高めていくのではないかと思います。 お知らせ メドレーでは、医療介護の求人サイト「 ジョブメドレー 」、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる 介護施設 の検索サイト「 介護のほんね 」、オンライン診療アプリ「 CLINICS 」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 www.medley.jp 医療や介護とは全く違う業界で経験を積んできたエンジニア・デザイナーが多いですが、こうした定期的な勉強会などで必要知識をインプットしながら開発しています。 メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております！

ジョブメドレーの開発運用を担当している 新居 です。 メドレーでは開発本部のメンバーの技術力底上げや課題解決を目的とした短期プロジェクト（タスクフォースと呼んでいます）を実施しています。この取り組みの一環として、6〜8 月はセキュリティ知識の底上げを目指した「セキュリティタスクフォース」を実施しました。今回は、その取り組み内容を紹介します。 背景 現在、メドレーの開発本部には約 20 名のエンジニアが在籍しており、それぞれ多種多様な開発経験やスキルセットを持ったエンジニアが集まっています。 そして、前職ではフロントエンド専門でやってきたエンジニアもサーバーサイドの開発を行ったり、またその逆のケースもあったりと、各自の専門領域にとらわれないスタイルでの開発を行うことも多々あります。 課題 そういった背景の中、エンジニアが増えていくにつれエンジニア間のスキルセットに差が生まれ、ばらつきが見られるようにもなっています。今後、更に組織が拡大していくのに伴い、こうしたエンジニア間のスキルセットの差も大きくなっていくことが懸念されます。 また、メドレーは医療ヘルスケア分野に向けてサービス提供を行っており、多くの個人情報を扱っていることはもちろん、医療・介護という領域の性質上、セキュリティには非常に気をつかう必要があります。データベースに入れて保守・運用している個人情報などの取り扱いや、システム改善や新機能開発などを行うときには必然的にセキュリティにも配慮して開発を進める必要があります。 そして背景のところでも述べたように、元々フロントエンド専門のエンジニアがサーバーサイドの開発に関わるケースや、そもそもサーバーサイド開発の経験が浅いエンジニアも中にはいて、サーバーサイドのセキュリティに関して自信がなかったり、具体的な対策方法がすぐに出てこないこともあるという課題がありました（当然ですが実際の開発では PR などでレビューして問題が起きないように対応しています）。 そこで、そういったメンバーのセキュリティ知識の底上げを行い、エンジニア間のスキルセットの差を縮めていくことが必要であると考えました。 取り組み 上述した通り、 スキルセットにばらつきや差が見られる 医療ヘルスケア分野は特にセキュリティに気を使う必要がある セキュリティに関して自信がない、具体的な対策方法がすぐに出てこないこともある といった課題感から、まずはフロントエンド専門でやってきたメンバーやサーバーサイド開発の経験が浅いメンバーをメインターゲットとして、セキュリティ知識の底上げをやっていくことにフォーカスしました。 目標としては、ウェブアプリケーション開発における最低限のセキュリティ知識や対策方法をしっかり再整理し、さらに開発で使っている Ruby on Rails 上でどのように対策するべきかを押さえるというところを目標におきました。 形式 形式としては、参加者に事前に教材の対象範囲を読んできてもらい、隔週開催の TechLunch（社内勉強会）終了後の約 20 分を利用して、内容の簡単な説明や補足、質疑応答、議論などを行う場（フォロー会）を設けました。 教材 以下を使用しました。 メイン教材：「IPA の安全なウェブサイトの作り方」 www.ipa.go.jp サブ教材：「Rails セキュリティガイド」 railsguides.jp メイン教材の「IPA の安全なウェブサイトの作り方」は、IPA が届出を受けた脆弱性関連情報を基にして作られており、セキュリティを考慮したウェブサイトを作る上での最低限の知識が整理できるだろうということで採用しました。 サブ教材の「Rails セキュリティガイド」は、Rails ではどのようにセキュリティの問題を回避しているのかといった方法が解説されており、実際の開発のときにどうすれば良いのかといったことが押さえられるだろうということで採用しました。 実際の開催スケジュールと、フォロー会の対象範囲はこちら。 取り組みを終えて 取り組みを終えて感じたこととしては以下になります。 技術的な観点 SQL インジェクションや XSS、CSRF などのメジャーな攻撃手法を参加者間で再整理できた 技術的に不安なところなどは「ここはこうですよね？」という感じで確かめ合うことができた 参加者が前職での経験談などをシェアしてくれる場面もあり、知見の共有ができた セキュリティに詳しいエンジニアも交えて話すことで、随所で効果的にツッコミをいただき、濃密な議論ができた ベテランエンジニアからは、昔流行った某サービスの某セキュリティ系障害の有名事例なども共有され、過去の歴史を知ることができる場となった 技術以外の観点 普段はチーム毎に黙々と仕事に取り組んでおり、チームを跨いであるひとつの話題（今回はセキュリティ）についてみんなと会話する機会は少ないので、知識の底上げはもちろんのこと、コミュニケーションの場としても良かった 今回のように質疑応答や議論ができる場を設けることにより、他のメンバーの経験や知見も効果的に共有することができ、教材の読み合わせや講義形式では得られない知識も共有でき、取り組みとしてはうまくいったかなあと思います。 まとめ ということで、今回はセキュリティタスクフォースについてご紹介しました。 セキュリティの知識はだれかひとりが押さえていれば良いというものではなく、開発に関わるエンジニア全員が最低限は押さえておく必要があると思います。 組織の拡大と共に、日々のプロダクトの運用・開発も大切ですが、それらを支えるエンジニアの知識の底上げなどの開発以外の部分もより大切になってきますし、そういった取り組みが組織力を高めていくのではないかと思います。 お知らせ メドレーでは、医療介護の求人サイト「 ジョブメドレー 」、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる 介護施設 の検索サイト「 介護のほんね 」、オンライン診療アプリ「 CLINICS 」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 www.medley.jp 医療や介護とは全く違う業界で経験を積んできたエンジニア・デザイナーが多いですが、こうした定期的な勉強会などで必要知識をインプットしながら開発しています。 メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております！

ジョブメドレーの開発運用を担当している 新居 です。 メドレーでは開発本部のメンバーの技術力底上げや課題解決を目的とした短期プロジェクト（タスクフォースと呼んでいます）を実施しています。この取り組みの一環として、6〜8 月はセキュリティ知識の底上げを目指した「セキュリティタスクフォース」を実施しました。今回は、その取り組み内容を紹介します。 背景 現在、メドレーの開発本部には約 20 名のエンジニアが在籍しており、それぞれ多種多様な開発経験やスキルセットを持ったエンジニアが集まっています。 そして、前職ではフロントエンド専門でやってきたエンジニアもサーバーサイドの開発を行ったり、またその逆のケースもあったりと、各自の専門領域にとらわれないスタイルでの開発を行うことも多々あります。 課題 そういった背景の中、エンジニアが増えていくにつれエンジニア間のスキルセットに差が生まれ、ばらつきが見られるようにもなっています。今後、更に組織が拡大していくのに伴い、こうしたエンジニア間のスキルセットの差も大きくなっていくことが懸念されます。 また、メドレーは医療ヘルスケア分野に向けてサービス提供を行っており、多くの個人情報を扱っていることはもちろん、医療・介護という領域の性質上、セキュリティには非常に気をつかう必要があります。データベースに入れて保守・運用している個人情報などの取り扱いや、システム改善や新機能開発などを行うときには必然的にセキュリティにも配慮して開発を進める必要があります。 そして背景のところでも述べたように、元々フロントエンド専門のエンジニアがサーバーサイドの開発に関わるケースや、そもそもサーバーサイド開発の経験が浅いエンジニアも中にはいて、サーバーサイドのセキュリティに関して自信がなかったり、具体的な対策方法がすぐに出てこないこともあるという課題がありました（当然ですが実際の開発では PR などでレビューして問題が起きないように対応しています）。 そこで、そういったメンバーのセキュリティ知識の底上げを行い、エンジニア間のスキルセットの差を縮めていくことが必要であると考えました。 取り組み 上述した通り、 スキルセットにばらつきや差が見られる 医療ヘルスケア分野は特にセキュリティに気を使う必要がある セキュリティに関して自信がない、具体的な対策方法がすぐに出てこないこともある といった課題感から、まずはフロントエンド専門でやってきたメンバーやサーバーサイド開発の経験が浅いメンバーをメインターゲットとして、セキュリティ知識の底上げをやっていくことにフォーカスしました。 目標としては、ウェブアプリケーション開発における最低限のセキュリティ知識や対策方法をしっかり再整理し、さらに開発で使っている Ruby on Rails 上でどのように対策するべきかを押さえるというところを目標におきました。 形式 形式としては、参加者に事前に教材の対象範囲を読んできてもらい、隔週開催の TechLunch（社内勉強会）終了後の約 20 分を利用して、内容の簡単な説明や補足、質疑応答、議論などを行う場（フォロー会）を設けました。 教材 以下を使用しました。 メイン教材：「IPA の安全なウェブサイトの作り方」 www.ipa.go.jp サブ教材：「Rails セキュリティガイド」 railsguides.jp メイン教材の「IPA の安全なウェブサイトの作り方」は、IPA が届出を受けた脆弱性関連情報を基にして作られており、セキュリティを考慮したウェブサイトを作る上での最低限の知識が整理できるだろうということで採用しました。 サブ教材の「Rails セキュリティガイド」は、Rails ではどのようにセキュリティの問題を回避しているのかといった方法が解説されており、実際の開発のときにどうすれば良いのかといったことが押さえられるだろうということで採用しました。 実際の開催スケジュールと、フォロー会の対象範囲はこちら。 取り組みを終えて 取り組みを終えて感じたこととしては以下になります。 技術的な観点 SQL インジェクションや XSS、CSRF などのメジャーな攻撃手法を参加者間で再整理できた 技術的に不安なところなどは「ここはこうですよね？」という感じで確かめ合うことができた 参加者が前職での経験談などをシェアしてくれる場面もあり、知見の共有ができた セキュリティに詳しいエンジニアも交えて話すことで、随所で効果的にツッコミをいただき、濃密な議論ができた ベテランエンジニアからは、昔流行った某サービスの某セキュリティ系障害の有名事例なども共有され、過去の歴史を知ることができる場となった 技術以外の観点 普段はチーム毎に黙々と仕事に取り組んでおり、チームを跨いであるひとつの話題（今回はセキュリティ）についてみんなと会話する機会は少ないので、知識の底上げはもちろんのこと、コミュニケーションの場としても良かった 今回のように質疑応答や議論ができる場を設けることにより、他のメンバーの経験や知見も効果的に共有することができ、教材の読み合わせや講義形式では得られない知識も共有でき、取り組みとしてはうまくいったかなあと思います。 まとめ ということで、今回はセキュリティタスクフォースについてご紹介しました。 セキュリティの知識はだれかひとりが押さえていれば良いというものではなく、開発に関わるエンジニア全員が最低限は押さえておく必要があると思います。 組織の拡大と共に、日々のプロダクトの運用・開発も大切ですが、それらを支えるエンジニアの知識の底上げなどの開発以外の部分もより大切になってきますし、そういった取り組みが組織力を高めていくのではないかと思います。 お知らせ メドレーでは、医療介護の求人サイト「 ジョブメドレー 」、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる 介護施設 の検索サイト「 介護のほんね 」、オンライン診療アプリ「 CLINICS 」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 www.medley.jp 医療や介護とは全く違う業界で経験を積んできたエンジニア・デザイナーが多いですが、こうした定期的な勉強会などで必要知識をインプットしながら開発しています。 メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております！

ジョブメドレーの開発運用を担当している 新居 です。 メドレーでは開発本部のメンバーの技術力底上げや課題解決を目的とした短期プロジェクト（タスクフォースと呼んでいます）を実施しています。この取り組みの一環として、6〜8 月はセキュリティ知識の底上げを目指した「セキュリティタスクフォース」を実施しました。今回は、その取り組み内容を紹介します。 背景 現在、メドレーの開発本部には約 20 名のエンジニアが在籍しており、それぞれ多種多様な開発経験やスキルセットを持ったエンジニアが集まっています。 そして、前職ではフロントエンド専門でやってきたエンジニアもサーバーサイドの開発を行ったり、またその逆のケースもあったりと、各自の専門領域にとらわれないスタイルでの開発を行うことも多々あります。 課題 そういった背景の中、エンジニアが増えていくにつれエンジニア間のスキルセットに差が生まれ、ばらつきが見られるようにもなっています。今後、更に組織が拡大していくのに伴い、こうしたエンジニア間のスキルセットの差も大きくなっていくことが懸念されます。 また、メドレーは医療ヘルスケア分野に向けてサービス提供を行っており、多くの個人情報を扱っていることはもちろん、医療・介護という領域の性質上、セキュリティには非常に気をつかう必要があります。データベースに入れて保守・運用している個人情報などの取り扱いや、システム改善や新機能開発などを行うときには必然的にセキュリティにも配慮して開発を進める必要があります。 そして背景のところでも述べたように、元々フロントエンド専門のエンジニアがサーバーサイドの開発に関わるケースや、そもそもサーバーサイド開発の経験が浅いエンジニアも中にはいて、サーバーサイドのセキュリティに関して自信がなかったり、具体的な対策方法がすぐに出てこないこともあるという課題がありました（当然ですが実際の開発では PR などでレビューして問題が起きないように対応しています）。 そこで、そういったメンバーのセキュリティ知識の底上げを行い、エンジニア間のスキルセットの差を縮めていくことが必要であると考えました。 取り組み 上述した通り、 スキルセットにばらつきや差が見られる 医療ヘルスケア分野は特にセキュリティに気を使う必要がある セキュリティに関して自信がない、具体的な対策方法がすぐに出てこないこともある といった課題感から、まずはフロントエンド専門でやってきたメンバーやサーバーサイド開発の経験が浅いメンバーをメインターゲットとして、セキュリティ知識の底上げをやっていくことにフォーカスしました。 目標としては、ウェブアプリケーション開発における最低限のセキュリティ知識や対策方法をしっかり再整理し、さらに開発で使っている Ruby on Rails 上でどのように対策するべきかを押さえるというところを目標におきました。 形式 形式としては、参加者に事前に教材の対象範囲を読んできてもらい、隔週開催の TechLunch（社内勉強会）終了後の約 20 分を利用して、内容の簡単な説明や補足、質疑応答、議論などを行う場（フォロー会）を設けました。 教材 以下を使用しました。 メイン教材：「IPA の安全なウェブサイトの作り方」 www.ipa.go.jp サブ教材：「Rails セキュリティガイド」 railsguides.jp メイン教材の「IPA の安全なウェブサイトの作り方」は、IPA が届出を受けた脆弱性関連情報を基にして作られており、セキュリティを考慮したウェブサイトを作る上での最低限の知識が整理できるだろうということで採用しました。 サブ教材の「Rails セキュリティガイド」は、Rails ではどのようにセキュリティの問題を回避しているのかといった方法が解説されており、実際の開発のときにどうすれば良いのかといったことが押さえられるだろうということで採用しました。 実際の開催スケジュールと、フォロー会の対象範囲はこちら。 取り組みを終えて 取り組みを終えて感じたこととしては以下になります。 技術的な観点 SQL インジェクションや XSS、CSRF などのメジャーな攻撃手法を参加者間で再整理できた 技術的に不安なところなどは「ここはこうですよね？」という感じで確かめ合うことができた 参加者が前職での経験談などをシェアしてくれる場面もあり、知見の共有ができた セキュリティに詳しいエンジニアも交えて話すことで、随所で効果的にツッコミをいただき、濃密な議論ができた ベテランエンジニアからは、昔流行った某サービスの某セキュリティ系障害の有名事例なども共有され、過去の歴史を知ることができる場となった 技術以外の観点 普段はチーム毎に黙々と仕事に取り組んでおり、チームを跨いであるひとつの話題（今回はセキュリティ）についてみんなと会話する機会は少ないので、知識の底上げはもちろんのこと、コミュニケーションの場としても良かった 今回のように質疑応答や議論ができる場を設けることにより、他のメンバーの経験や知見も効果的に共有することができ、教材の読み合わせや講義形式では得られない知識も共有でき、取り組みとしてはうまくいったかなあと思います。 まとめ ということで、今回はセキュリティタスクフォースについてご紹介しました。 セキュリティの知識はだれかひとりが押さえていれば良いというものではなく、開発に関わるエンジニア全員が最低限は押さえておく必要があると思います。 組織の拡大と共に、日々のプロダクトの運用・開発も大切ですが、それらを支えるエンジニアの知識の底上げなどの開発以外の部分もより大切になってきますし、そういった取り組みが組織力を高めていくのではないかと思います。 お知らせ メドレーでは、医療介護の求人サイト「 ジョブメドレー 」、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる 介護施設 の検索サイト「 介護のほんね 」、オンライン診療アプリ「 CLINICS 」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 www.medley.jp 医療や介護とは全く違う業界で経験を積んできたエンジニア・デザイナーが多いですが、こうした定期的な勉強会などで必要知識をインプットしながら開発しています。 メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております！

ジョブメドレーの開発運用を担当している 新居 です。 メドレーでは開発本部のメンバーの技術力底上げや課題解決を目的とした短期プロジェクト（タスクフォースと呼んでいます）を実施しています。この取り組みの一環として、6〜8 月はセキュリティ知識の底上げを目指した「セキュリティタスクフォース」を実施しました。今回は、その取り組み内容を紹介します。 背景 現在、メドレーの開発本部には約 20 名のエンジニアが在籍しており、それぞれ多種多様な開発経験やスキルセットを持ったエンジニアが集まっています。 そして、前職ではフロントエンド専門でやってきたエンジニアもサーバーサイドの開発を行ったり、またその逆のケースもあったりと、各自の専門領域にとらわれないスタイルでの開発を行うことも多々あります。 課題 そういった背景の中、エンジニアが増えていくにつれエンジニア間のスキルセットに差が生まれ、ばらつきが見られるようにもなっています。今後、更に組織が拡大していくのに伴い、こうしたエンジニア間のスキルセットの差も大きくなっていくことが懸念されます。 また、メドレーは医療ヘルスケア分野に向けてサービス提供を行っており、多くの個人情報を扱っていることはもちろん、医療・介護という領域の性質上、セキュリティには非常に気をつかう必要があります。データベースに入れて保守・運用している個人情報などの取り扱いや、システム改善や新機能開発などを行うときには必然的にセキュリティにも配慮して開発を進める必要があります。 そして背景のところでも述べたように、元々フロントエンド専門のエンジニアがサーバーサイドの開発に関わるケースや、そもそもサーバーサイド開発の経験が浅いエンジニアも中にはいて、サーバーサイドのセキュリティに関して自信がなかったり、具体的な対策方法がすぐに出てこないこともあるという課題がありました（当然ですが実際の開発では PR などでレビューして問題が起きないように対応しています）。 そこで、そういったメンバーのセキュリティ知識の底上げを行い、エンジニア間のスキルセットの差を縮めていくことが必要であると考えました。 取り組み 上述した通り、 スキルセットにばらつきや差が見られる 医療ヘルスケア分野は特にセキュリティに気を使う必要がある セキュリティに関して自信がない、具体的な対策方法がすぐに出てこないこともある といった課題感から、まずはフロントエンド専門でやってきたメンバーやサーバーサイド開発の経験が浅いメンバーをメインターゲットとして、セキュリティ知識の底上げをやっていくことにフォーカスしました。 目標としては、ウェブアプリケーション開発における最低限のセキュリティ知識や対策方法をしっかり再整理し、さらに開発で使っている Ruby on Rails 上でどのように対策するべきかを押さえるというところを目標におきました。 形式 形式としては、参加者に事前に教材の対象範囲を読んできてもらい、隔週開催の TechLunch（社内勉強会）終了後の約 20 分を利用して、内容の簡単な説明や補足、質疑応答、議論などを行う場（フォロー会）を設けました。 教材 以下を使用しました。 メイン教材：「IPA の安全なウェブサイトの作り方」 www.ipa.go.jp サブ教材：「Rails セキュリティガイド」 railsguides.jp メイン教材の「IPA の安全なウェブサイトの作り方」は、IPA が届出を受けた脆弱性関連情報を基にして作られており、セキュリティを考慮したウェブサイトを作る上での最低限の知識が整理できるだろうということで採用しました。 サブ教材の「Rails セキュリティガイド」は、Rails ではどのようにセキュリティの問題を回避しているのかといった方法が解説されており、実際の開発のときにどうすれば良いのかといったことが押さえられるだろうということで採用しました。 実際の開催スケジュールと、フォロー会の対象範囲はこちら。 取り組みを終えて 取り組みを終えて感じたこととしては以下になります。 技術的な観点 SQL インジェクションや XSS、CSRF などのメジャーな攻撃手法を参加者間で再整理できた 技術的に不安なところなどは「ここはこうですよね？」という感じで確かめ合うことができた 参加者が前職での経験談などをシェアしてくれる場面もあり、知見の共有ができた セキュリティに詳しいエンジニアも交えて話すことで、随所で効果的にツッコミをいただき、濃密な議論ができた ベテランエンジニアからは、昔流行った某サービスの某セキュリティ系障害の有名事例なども共有され、過去の歴史を知ることができる場となった 技術以外の観点 普段はチーム毎に黙々と仕事に取り組んでおり、チームを跨いであるひとつの話題（今回はセキュリティ）についてみんなと会話する機会は少ないので、知識の底上げはもちろんのこと、コミュニケーションの場としても良かった 今回のように質疑応答や議論ができる場を設けることにより、他のメンバーの経験や知見も効果的に共有することができ、教材の読み合わせや講義形式では得られない知識も共有でき、取り組みとしてはうまくいったかなあと思います。 まとめ ということで、今回はセキュリティタスクフォースについてご紹介しました。 セキュリティの知識はだれかひとりが押さえていれば良いというものではなく、開発に関わるエンジニア全員が最低限は押さえておく必要があると思います。 組織の拡大と共に、日々のプロダクトの運用・開発も大切ですが、それらを支えるエンジニアの知識の底上げなどの開発以外の部分もより大切になってきますし、そういった取り組みが組織力を高めていくのではないかと思います。 お知らせ メドレーでは、医療介護の求人サイト「 ジョブメドレー 」、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる 介護施設 の検索サイト「 介護のほんね 」、オンライン診療アプリ「 CLINICS 」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 www.medley.jp 医療や介護とは全く違う業界で経験を積んできたエンジニア・デザイナーが多いですが、こうした定期的な勉強会などで必要知識をインプットしながら開発しています。 メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております！

ジョブメドレーの開発運用を担当している 新居 です。 メドレーでは開発本部のメンバーの技術力底上げや課題解決を目的とした短期プロジェクト（タスクフォースと呼んでいます）を実施しています。この取り組みの一環として、6〜8 月はセキュリティ知識の底上げを目指した「セキュリティタスクフォース」を実施しました。今回は、その取り組み内容を紹介します。 背景 現在、メドレーの開発本部には約 20 名のエンジニアが在籍しており、それぞれ多種多様な開発経験やスキルセットを持ったエンジニアが集まっています。 そして、前職ではフロントエンド専門でやってきたエンジニアもサーバーサイドの開発を行ったり、またその逆のケースもあったりと、各自の専門領域にとらわれないスタイルでの開発を行うことも多々あります。 課題 そういった背景の中、エンジニアが増えていくにつれエンジニア間のスキルセットに差が生まれ、ばらつきが見られるようにもなっています。今後、更に組織が拡大していくのに伴い、こうしたエンジニア間のスキルセットの差も大きくなっていくことが懸念されます。 また、メドレーは医療ヘルスケア分野に向けてサービス提供を行っており、多くの個人情報を扱っていることはもちろん、医療・介護という領域の性質上、セキュリティには非常に気をつかう必要があります。データベースに入れて保守・運用している個人情報などの取り扱いや、システム改善や新機能開発などを行うときには必然的にセキュリティにも配慮して開発を進める必要があります。 そして背景のところでも述べたように、元々フロントエンド専門のエンジニアがサーバーサイドの開発に関わるケースや、そもそもサーバーサイド開発の経験が浅いエンジニアも中にはいて、サーバーサイドのセキュリティに関して自信がなかったり、具体的な対策方法がすぐに出てこないこともあるという課題がありました（当然ですが実際の開発では PR などでレビューして問題が起きないように対応しています）。 そこで、そういったメンバーのセキュリティ知識の底上げを行い、エンジニア間のスキルセットの差を縮めていくことが必要であると考えました。 取り組み 上述した通り、 スキルセットにばらつきや差が見られる 医療ヘルスケア分野は特にセキュリティに気を使う必要がある セキュリティに関して自信がない、具体的な対策方法がすぐに出てこないこともある といった課題感から、まずはフロントエンド専門でやってきたメンバーやサーバーサイド開発の経験が浅いメンバーをメインターゲットとして、セキュリティ知識の底上げをやっていくことにフォーカスしました。 目標としては、ウェブアプリケーション開発における最低限のセキュリティ知識や対策方法をしっかり再整理し、さらに開発で使っている Ruby on Rails 上でどのように対策するべきかを押さえるというところを目標におきました。 形式 形式としては、参加者に事前に教材の対象範囲を読んできてもらい、隔週開催の TechLunch（社内勉強会）終了後の約 20 分を利用して、内容の簡単な説明や補足、質疑応答、議論などを行う場（フォロー会）を設けました。 教材 以下を使用しました。 メイン教材：「IPA の安全なウェブサイトの作り方」 www.ipa.go.jp サブ教材：「Rails セキュリティガイド」 railsguides.jp メイン教材の「IPA の安全なウェブサイトの作り方」は、IPA が届出を受けた脆弱性関連情報を基にして作られており、セキュリティを考慮したウェブサイトを作る上での最低限の知識が整理できるだろうということで採用しました。 サブ教材の「Rails セキュリティガイド」は、Rails ではどのようにセキュリティの問題を回避しているのかといった方法が解説されており、実際の開発のときにどうすれば良いのかといったことが押さえられるだろうということで採用しました。 実際の開催スケジュールと、フォロー会の対象範囲はこちら。 取り組みを終えて 取り組みを終えて感じたこととしては以下になります。 技術的な観点 SQL インジェクションや XSS、CSRF などのメジャーな攻撃手法を参加者間で再整理できた 技術的に不安なところなどは「ここはこうですよね？」という感じで確かめ合うことができた 参加者が前職での経験談などをシェアしてくれる場面もあり、知見の共有ができた セキュリティに詳しいエンジニアも交えて話すことで、随所で効果的にツッコミをいただき、濃密な議論ができた ベテランエンジニアからは、昔流行った某サービスの某セキュリティ系障害の有名事例なども共有され、過去の歴史を知ることができる場となった 技術以外の観点 普段はチーム毎に黙々と仕事に取り組んでおり、チームを跨いであるひとつの話題（今回はセキュリティ）についてみんなと会話する機会は少ないので、知識の底上げはもちろんのこと、コミュニケーションの場としても良かった 今回のように質疑応答や議論ができる場を設けることにより、他のメンバーの経験や知見も効果的に共有することができ、教材の読み合わせや講義形式では得られない知識も共有でき、取り組みとしてはうまくいったかなあと思います。 まとめ ということで、今回はセキュリティタスクフォースについてご紹介しました。 セキュリティの知識はだれかひとりが押さえていれば良いというものではなく、開発に関わるエンジニア全員が最低限は押さえておく必要があると思います。 組織の拡大と共に、日々のプロダクトの運用・開発も大切ですが、それらを支えるエンジニアの知識の底上げなどの開発以外の部分もより大切になってきますし、そういった取り組みが組織力を高めていくのではないかと思います。 お知らせ メドレーでは、医療介護の求人サイト「 ジョブメドレー 」、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる 介護施設 の検索サイト「 介護のほんね 」、オンライン診療アプリ「 CLINICS 」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 www.medley.jp 医療や介護とは全く違う業界で経験を積んできたエンジニア・デザイナーが多いですが、こうした定期的な勉強会などで必要知識をインプットしながら開発しています。 メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております！

メドレー開発本部の nakatani です。 開発本部で定期的に開催している勉強会「TechLunch」で、 runit という unix のプロセススーパバイザについてお話しました。 その内容について紹介させていただきます。 runit 自体は特に目新しい技術ではなく(Linux の busybox に収められていたりする枯れた技術です)、大して難しい話題でもありません。 ただ、個人的には便利に使っている 手放せないツール であり、もしスーパバイザというものの存在を知らずに 使わずにいる人がいると勿体無いなあ という思いから、TechLunch のテーマとして取り上げた次第です。 runit とはなんなのか プロセスをデーモンとして立ち上げて、プロセスが死んでも再度起動し続けてくれるツール郡です。C 言語で開発されています。 Linux などの unix ではたいてい標準で init, Upstart, Systemd, launchd などのスーパバイザが組み込まれています。 runit はそれらと同じような位置づけのものです。 qmail の作者である djb が作った daemontools の後継のプロダクトです。 runit があると何が便利なのか ■ マシンが起動しているかぎり、プロセスを動作させ続けることができる マシンを立ち上げたあとに、起動コマンドを叩いたり、プロセスが落ちたときに再起動をする必要がありません。 また、フォアグラウンドで動作するプロセスを起動した後に、端末を切り離す操作をする必要もありません。 ただ、これは他のスーパバイザでも同じことが実現できます。 ■ その場しのぎで作ったスクリプトを、ほぼそのままデーモン化できる Shell, Ruby, Perl, Haskell どのような言語で作ったスクリプトであっても、 シェルなどで実行可能なファイルがあれば、それをそのままデーモンとして実行することができます 。 ■ スクリプトの標準出力をそのままログファイルとして扱うことができる svlogd というプログラムが、デーモンの標準出力をログ化し、ローテーションなどの面倒も見てくれます。 自作のデーモンが思った通りに動かない際のデバッグが容易です。 macOS への導入方法 macOS に導入するための手順を記載します。詳しくはスライドや runit のドキュメントなどを理解して使うようにしてください。 Xcode や Homebrew を macOS に導入していることが前提です。 /service を root の runit ディレクトリとして設定する手順 $ brew install runit # macports feels better. $ sudo mkdir /service $ sudo cat << EOF | sudo tee /Library/LaunchDaemons/runit.plist <?xml version='1.0' encoding='UTF-8'?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "https://www.apple.com/DTDs/PropertyList-1.0.dtd" > <plist version='1.0'> <dict> <key>Label</key><string>runit</string> <key>ProgramArguments</key> <array> <string>sh</string><string>-c</string> <string>PATH="/usr/local/sbin:/usr/local/bin: $PATH " exec '/usr/local/bin/runsvdir' '/service' </string> <string>;</string> <string>--pid=exec</string> </array> <key>Debug</key><false/><key>Disabled</key><true/><key>KeepAlive</key><true/> </dict> </plist> EOF $ launchctl load -w > /Library/LaunchDaemons/runit.plist $ launchctl list | grep runit 自作スクリプトをデーモンにする手順 $ cd /service/ $ sudo mkdir -p hello/log # log を同時につくると runsvdir が log の準備もする $ cd hello $ sudo cat << EOF | sudo tee run #!/usr/bin/env ruby # 自作スクリプト while true puts("hello ruby #{Time.now.to_i % 100}"); STDOUT.flush(); sleep(1); end EOF $ sudo cat << EOF | sudo tee log/run #!/bin/sh exec svlogd -ttt . EOF $ sudo chmod 755 run log/run $ tail -F log/current # ログが見られる。 $ sudo sv st . # daemon の状態を確認する。 run: .: (pid 35517 ) 46s; run: log: (pid 34727 ) 456s $ sudo sv st /service/hello/ # ディレクトリの指定方法は自由。 $ sudo sv t . # TERM シグナルを daemon に送る $ sudo sv st . run: .: (pid 35589 ) 1s; run: log: (pid 34727 ) 470s # 起動時間が 1s になってる。 まとめ 結局のところ、**「使えばわかるし使わないと便利さがよくわからない」**というのが正直なところです。 そのため、TechLunch においては、 使うための手順 を時間をかけて解説をするようにしました。 みなさんも興味があれば、ぜひ導入して使ってみてください。 僕自身、開発マシンである macbook pro に runit を入れて、開発環境の Ruby や MongoDB, Elasticsearch, Nginx などのサーバ群、 定期的に動かしたいちょっとしたスクリプトなどを runit で管理しています。 異なる設定のサーバ群を一つのマシンに同居させる場合も、設定ファイルを分けて別ポートで立ち上げたりしています。 以前のプロジェクトでは本番環境を runit で構築したこともありますし、今のプロジェクトでも、たまったゴミデータを削除し続けるスクリプトを runit で対応してそのまま放置(放置しても OK なくらいメンテナンスフリー)していたりします。 最近はクラウドやコンテナ技術が活況であり、環境を抽象化しようという流れがあります。しかしながら、そもそもプロセスや UNIX OS 自体が環境を抽象化するための技術群です。そういった基本的な技術と仲良くすることで、物事がシンプルになることがあるのではないかと考えたりしながら、日々開発に取り組んでいます。 お知らせ メドレーでは、医療介護の求人サイト「 ジョブメドレー 」、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」、オンライン診療アプリ「 CLINICS 」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております。

メドレー開発本部の nakatani です。 開発本部で定期的に開催している勉強会「TechLunch」で、 runit という unix のプロセススーパバイザについてお話しました。 その内容について紹介させていただきます。 runit 自体は特に目新しい技術ではなく(Linux の busybox に収められていたりする枯れた技術です)、大して難しい話題でもありません。 ただ、個人的には便利に使っている 手放せないツール であり、もしスーパバイザというものの存在を知らずに 使わずにいる人がいると勿体無いなあ という思いから、TechLunch のテーマとして取り上げた次第です。 runit とはなんなのか プロセスをデーモンとして立ち上げて、プロセスが死んでも再度起動し続けてくれるツール郡です。C 言語で開発されています。 Linux などの unix ではたいてい標準で init, Upstart, Systemd, launchd などのスーパバイザが組み込まれています。 runit はそれらと同じような位置づけのものです。 qmail の作者である djb が作った daemontools の後継のプロダクトです。 runit があると何が便利なのか ■ マシンが起動しているかぎり、プロセスを動作させ続けることができる マシンを立ち上げたあとに、起動コマンドを叩いたり、プロセスが落ちたときに再起動をする必要がありません。 また、フォアグラウンドで動作するプロセスを起動した後に、端末を切り離す操作をする必要もありません。 ただ、これは他のスーパバイザでも同じことが実現できます。 ■ その場しのぎで作ったスクリプトを、ほぼそのままデーモン化できる Shell, Ruby, Perl, Haskell どのような言語で作ったスクリプトであっても、 シェルなどで実行可能なファイルがあれば、それをそのままデーモンとして実行することができます 。 ■ スクリプトの標準出力をそのままログファイルとして扱うことができる svlogd というプログラムが、デーモンの標準出力をログ化し、ローテーションなどの面倒も見てくれます。 自作のデーモンが思った通りに動かない際のデバッグが容易です。 macOS への導入方法 macOS に導入するための手順を記載します。詳しくはスライドや runit のドキュメントなどを理解して使うようにしてください。 Xcode や Homebrew を macOS に導入していることが前提です。 /service を root の runit ディレクトリとして設定する手順 $ brew install runit # macports feels better. $ sudo mkdir /service $ sudo cat << EOF | sudo tee /Library/LaunchDaemons/runit.plist <?xml version='1.0' encoding='UTF-8'?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "https://www.apple.com/DTDs/PropertyList-1.0.dtd" > <plist version='1.0'> <dict> <key>Label</key><string>runit</string> <key>ProgramArguments</key> <array> <string>sh</string><string>-c</string> <string>PATH="/usr/local/sbin:/usr/local/bin: $PATH " exec '/usr/local/bin/runsvdir' '/service' </string> <string>;</string> <string>--pid=exec</string> </array> <key>Debug</key><false/><key>Disabled</key><true/><key>KeepAlive</key><true/> </dict> </plist> EOF $ launchctl load -w > /Library/LaunchDaemons/runit.plist $ launchctl list | grep runit 自作スクリプトをデーモンにする手順 $ cd /service/ $ sudo mkdir -p hello/log # log を同時につくると runsvdir が log の準備もする $ cd hello $ sudo cat << EOF | sudo tee run #!/usr/bin/env ruby # 自作スクリプト while true puts("hello ruby #{Time.now.to_i % 100}"); STDOUT.flush(); sleep(1); end EOF $ sudo cat << EOF | sudo tee log/run #!/bin/sh exec svlogd -ttt . EOF $ sudo chmod 755 run log/run $ tail -F log/current # ログが見られる。 $ sudo sv st . # daemon の状態を確認する。 run: .: (pid 35517 ) 46s; run: log: (pid 34727 ) 456s $ sudo sv st /service/hello/ # ディレクトリの指定方法は自由。 $ sudo sv t . # TERM シグナルを daemon に送る $ sudo sv st . run: .: (pid 35589 ) 1s; run: log: (pid 34727 ) 470s # 起動時間が 1s になってる。 まとめ 結局のところ、**「使えばわかるし使わないと便利さがよくわからない」**というのが正直なところです。 そのため、TechLunch においては、 使うための手順 を時間をかけて解説をするようにしました。 みなさんも興味があれば、ぜひ導入して使ってみてください。 僕自身、開発マシンである macbook pro に runit を入れて、開発環境の Ruby や MongoDB, Elasticsearch, Nginx などのサーバ群、 定期的に動かしたいちょっとしたスクリプトなどを runit で管理しています。 異なる設定のサーバ群を一つのマシンに同居させる場合も、設定ファイルを分けて別ポートで立ち上げたりしています。 以前のプロジェクトでは本番環境を runit で構築したこともありますし、今のプロジェクトでも、たまったゴミデータを削除し続けるスクリプトを runit で対応してそのまま放置(放置しても OK なくらいメンテナンスフリー)していたりします。 最近はクラウドやコンテナ技術が活況であり、環境を抽象化しようという流れがあります。しかしながら、そもそもプロセスや UNIX OS 自体が環境を抽象化するための技術群です。そういった基本的な技術と仲良くすることで、物事がシンプルになることがあるのではないかと考えたりしながら、日々開発に取り組んでいます。 お知らせ メドレーでは、医療介護の求人サイト「 ジョブメドレー 」、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」、オンライン診療アプリ「 CLINICS 」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 https://www.medley.jp/recruit/creative.html メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております。

メドレー開発本部の nakatani です。 開発本部で定期的に開催している勉強会「TechLunch」で、 runit という unix のプロセススーパバイザについてお話しました。 その内容について紹介させていただきます。 runit 自体は特に目新しい技術ではなく(Linux の busybox に収められていたりする枯れた技術です)、大して難しい話題でもありません。 ただ、個人的には便利に使っている 手放せないツール であり、もしスーパバイザというものの存在を知らずに 使わずにいる人がいると勿体無いなあ という思いから、TechLunch のテーマとして取り上げた次第です。 runit とはなんなのか プロセスをデーモンとして立ち上げて、プロセスが死んでも再度起動し続けてくれるツール郡です。C 言語で開発されています。 Linux などの unix ではたいてい標準で init, Upstart, Systemd, launchd などのスーパバイザが組み込まれています。 runit はそれらと同じような位置づけのものです。 qmail の作者である djb が作った daemontools の後継のプロダクトです。 runit があると何が便利なのか ■ マシンが起動しているかぎり、プロセスを動作させ続けることができる マシンを立ち上げたあとに、起動コマンドを叩いたり、プロセスが落ちたときに再起動をする必要がありません。 また、フォアグラウンドで動作するプロセスを起動した後に、端末を切り離す操作をする必要もありません。 ただ、これは他のスーパバイザでも同じことが実現できます。 ■ その場しのぎで作ったスクリプトを、ほぼそのままデーモン化できる Shell, Ruby, Perl, Haskell どのような言語で作ったスクリプトであっても、 シェルなどで実行可能なファイルがあれば、それをそのままデーモンとして実行することができます 。 ■ スクリプトの標準出力をそのままログファイルとして扱うことができる svlogd というプログラムが、デーモンの標準出力をログ化し、ローテーションなどの面倒も見てくれます。 自作のデーモンが思った通りに動かない際のデバッグが容易です。 macOS への導入方法 macOS に導入するための手順を記載します。詳しくはスライドや runit のドキュメントなどを理解して使うようにしてください。 Xcode や Homebrew を macOS に導入していることが前提です。 /service を root の runit ディレクトリとして設定する手順 $ brew install runit # macports feels better. $ sudo mkdir /service $ sudo cat << EOF | sudo tee /Library/LaunchDaemons/runit.plist <?xml version='1.0' encoding='UTF-8'?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "https://www.apple.com/DTDs/PropertyList-1.0.dtd" > <plist version='1.0'> <dict> <key>Label</key><string>runit</string> <key>ProgramArguments</key> <array> <string>sh</string><string>-c</string> <string>PATH="/usr/local/sbin:/usr/local/bin: $PATH " exec '/usr/local/bin/runsvdir' '/service' </string> <string>;</string> <string>--pid=exec</string> </array> <key>Debug</key><false/><key>Disabled</key><true/><key>KeepAlive</key><true/> </dict> </plist> EOF $ launchctl load -w > /Library/LaunchDaemons/runit.plist $ launchctl list | grep runit 自作スクリプトをデーモンにする手順 $ cd /service/ $ sudo mkdir -p hello/log # log を同時につくると runsvdir が log の準備もする $ cd hello $ sudo cat << EOF | sudo tee run #!/usr/bin/env ruby # 自作スクリプト while true puts("hello ruby #{Time.now.to_i % 100}"); STDOUT.flush(); sleep(1); end EOF $ sudo cat << EOF | sudo tee log/run #!/bin/sh exec svlogd -ttt . EOF $ sudo chmod 755 run log/run $ tail -F log/current # ログが見られる。 $ sudo sv st . # daemon の状態を確認する。 run: .: (pid 35517 ) 46s; run: log: (pid 34727 ) 456s $ sudo sv st /service/hello/ # ディレクトリの指定方法は自由。 $ sudo sv t . # TERM シグナルを daemon に送る $ sudo sv st . run: .: (pid 35589 ) 1s; run: log: (pid 34727 ) 470s # 起動時間が 1s になってる。 まとめ 結局のところ、**「使えばわかるし使わないと便利さがよくわからない」**というのが正直なところです。 そのため、TechLunch においては、 使うための手順 を時間をかけて解説をするようにしました。 みなさんも興味があれば、ぜひ導入して使ってみてください。 僕自身、開発マシンである macbook pro に runit を入れて、開発環境の Ruby や MongoDB, Elasticsearch, Nginx などのサーバ群、 定期的に動かしたいちょっとしたスクリプトなどを runit で管理しています。 異なる設定のサーバ群を一つのマシンに同居させる場合も、設定ファイルを分けて別ポートで立ち上げたりしています。 以前のプロジェクトでは本番環境を runit で構築したこともありますし、今のプロジェクトでも、たまったゴミデータを削除し続けるスクリプトを runit で対応してそのまま放置(放置しても OK なくらいメンテナンスフリー)していたりします。 最近はクラウドやコンテナ技術が活況であり、環境を抽象化しようという流れがあります。しかしながら、そもそもプロセスや UNIX OS 自体が環境を抽象化するための技術群です。そういった基本的な技術と仲良くすることで、物事がシンプルになることがあるのではないかと考えたりしながら、日々開発に取り組んでいます。 お知らせ メドレーでは、医療介護の求人サイト「 ジョブメドレー 」、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」、オンライン診療アプリ「 CLINICS 」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております。

メドレー開発本部の nakatani です。 開発本部で定期的に開催している勉強会「TechLunch」で、 runit という unix のプロセススーパバイザについてお話しました。 その内容について紹介させていただきます。 runit 自体は特に目新しい技術ではなく(Linux の busybox に収められていたりする枯れた技術です)、大して難しい話題でもありません。 ただ、個人的には便利に使っている 手放せないツール であり、もしスーパバイザというものの存在を知らずに 使わずにいる人がいると勿体無いなあ という思いから、TechLunch のテーマとして取り上げた次第です。 runit とはなんなのか プロセスをデーモンとして立ち上げて、プロセスが死んでも再度起動し続けてくれるツール郡です。C 言語で開発されています。 Linux などの unix ではたいてい標準で init, Upstart, Systemd, launchd などのスーパバイザが組み込まれています。 runit はそれらと同じような位置づけのものです。 qmail の作者である djb が作った daemontools の後継のプロダクトです。 runit があると何が便利なのか ■ マシンが起動しているかぎり、プロセスを動作させ続けることができる マシンを立ち上げたあとに、起動コマンドを叩いたり、プロセスが落ちたときに再起動をする必要がありません。 また、フォアグラウンドで動作するプロセスを起動した後に、端末を切り離す操作をする必要もありません。 ただ、これは他のスーパバイザでも同じことが実現できます。 ■ その場しのぎで作ったスクリプトを、ほぼそのままデーモン化できる Shell, Ruby, Perl, Haskell どのような言語で作ったスクリプトであっても、 シェルなどで実行可能なファイルがあれば、それをそのままデーモンとして実行することができます 。 ■ スクリプトの標準出力をそのままログファイルとして扱うことができる svlogd というプログラムが、デーモンの標準出力をログ化し、ローテーションなどの面倒も見てくれます。 自作のデーモンが思った通りに動かない際のデバッグが容易です。 macOS への導入方法 macOS に導入するための手順を記載します。詳しくはスライドや runit のドキュメントなどを理解して使うようにしてください。 Xcode や Homebrew を macOS に導入していることが前提です。 /service を root の runit ディレクトリとして設定する手順 $ brew install runit # macports feels better. $ sudo mkdir /service $ sudo cat << EOF | sudo tee /Library/LaunchDaemons/runit.plist <?xml version='1.0' encoding='UTF-8'?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "https://www.apple.com/DTDs/PropertyList-1.0.dtd" > <plist version='1.0'> <dict> <key>Label</key><string>runit</string> <key>ProgramArguments</key> <array> <string>sh</string><string>-c</string> <string>PATH="/usr/local/sbin:/usr/local/bin: $PATH " exec '/usr/local/bin/runsvdir' '/service' </string> <string>;</string> <string>--pid=exec</string> </array> <key>Debug</key><false/><key>Disabled</key><true/><key>KeepAlive</key><true/> </dict> </plist> EOF $ launchctl load -w > /Library/LaunchDaemons/runit.plist $ launchctl list | grep runit 自作スクリプトをデーモンにする手順 $ cd /service/ $ sudo mkdir -p hello/log # log を同時につくると runsvdir が log の準備もする $ cd hello $ sudo cat << EOF | sudo tee run #!/usr/bin/env ruby # 自作スクリプト while true puts("hello ruby #{Time.now.to_i % 100}"); STDOUT.flush(); sleep(1); end EOF $ sudo cat << EOF | sudo tee log/run #!/bin/sh exec svlogd -ttt . EOF $ sudo chmod 755 run log/run $ tail -F log/current # ログが見られる。 $ sudo sv st . # daemon の状態を確認する。 run: .: (pid 35517 ) 46s; run: log: (pid 34727 ) 456s $ sudo sv st /service/hello/ # ディレクトリの指定方法は自由。 $ sudo sv t . # TERM シグナルを daemon に送る $ sudo sv st . run: .: (pid 35589 ) 1s; run: log: (pid 34727 ) 470s # 起動時間が 1s になってる。 まとめ 結局のところ、**「使えばわかるし使わないと便利さがよくわからない」**というのが正直なところです。 そのため、TechLunch においては、 使うための手順 を時間をかけて解説をするようにしました。 みなさんも興味があれば、ぜひ導入して使ってみてください。 僕自身、開発マシンである macbook pro に runit を入れて、開発環境の Ruby や MongoDB, Elasticsearch, Nginx などのサーバ群、 定期的に動かしたいちょっとしたスクリプトなどを runit で管理しています。 異なる設定のサーバ群を一つのマシンに同居させる場合も、設定ファイルを分けて別ポートで立ち上げたりしています。 以前のプロジェクトでは本番環境を runit で構築したこともありますし、今のプロジェクトでも、たまったゴミデータを削除し続けるスクリプトを runit で対応してそのまま放置(放置しても OK なくらいメンテナンスフリー)していたりします。 最近はクラウドやコンテナ技術が活況であり、環境を抽象化しようという流れがあります。しかしながら、そもそもプロセスや UNIX OS 自体が環境を抽象化するための技術群です。そういった基本的な技術と仲良くすることで、物事がシンプルになることがあるのではないかと考えたりしながら、日々開発に取り組んでいます。 お知らせ メドレーでは、医療介護の求人サイト「 ジョブメドレー 」、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」、オンライン診療アプリ「 CLINICS 」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております。

メドレー開発本部の nakatani です。 開発本部で定期的に開催している勉強会「TechLunch」で、 runit という unix のプロセススーパバイザについてお話しました。 その内容について紹介させていただきます。 runit 自体は特に目新しい技術ではなく(Linux の busybox に収められていたりする枯れた技術です)、大して難しい話題でもありません。 ただ、個人的には便利に使っている 手放せないツール であり、もしスーパバイザというものの存在を知らずに 使わずにいる人がいると勿体無いなあ という思いから、TechLunch のテーマとして取り上げた次第です。 runit とはなんなのか プロセスをデーモンとして立ち上げて、プロセスが死んでも再度起動し続けてくれるツール郡です。C 言語で開発されています。 Linux などの unix ではたいてい標準で init, Upstart, Systemd, launchd などのスーパバイザが組み込まれています。 runit はそれらと同じような位置づけのものです。 qmail の作者である djb が作った daemontools の後継のプロダクトです。 runit があると何が便利なのか ■ マシンが起動しているかぎり、プロセスを動作させ続けることができる マシンを立ち上げたあとに、起動コマンドを叩いたり、プロセスが落ちたときに再起動をする必要がありません。 また、フォアグラウンドで動作するプロセスを起動した後に、端末を切り離す操作をする必要もありません。 ただ、これは他のスーパバイザでも同じことが実現できます。 ■ その場しのぎで作ったスクリプトを、ほぼそのままデーモン化できる Shell, Ruby, Perl, Haskell どのような言語で作ったスクリプトであっても、 シェルなどで実行可能なファイルがあれば、それをそのままデーモンとして実行することができます 。 ■ スクリプトの標準出力をそのままログファイルとして扱うことができる svlogd というプログラムが、デーモンの標準出力をログ化し、ローテーションなどの面倒も見てくれます。 自作のデーモンが思った通りに動かない際のデバッグが容易です。 macOS への導入方法 macOS に導入するための手順を記載します。詳しくはスライドや runit のドキュメントなどを理解して使うようにしてください。 Xcode や Homebrew を macOS に導入していることが前提です。 /service を root の runit ディレクトリとして設定する手順 $ brew install runit # macports feels better. $ sudo mkdir /service $ sudo cat << EOF | sudo tee /Library/LaunchDaemons/runit.plist <?xml version='1.0' encoding='UTF-8'?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "https://www.apple.com/DTDs/PropertyList-1.0.dtd" > <plist version='1.0'> <dict> <key>Label</key><string>runit</string> <key>ProgramArguments</key> <array> <string>sh</string><string>-c</string> <string>PATH="/usr/local/sbin:/usr/local/bin: $PATH " exec '/usr/local/bin/runsvdir' '/service' </string> <string>;</string> <string>--pid=exec</string> </array> <key>Debug</key><false/><key>Disabled</key><true/><key>KeepAlive</key><true/> </dict> </plist> EOF $ launchctl load -w > /Library/LaunchDaemons/runit.plist $ launchctl list | grep runit 自作スクリプトをデーモンにする手順 $ cd /service/ $ sudo mkdir -p hello/log # log を同時につくると runsvdir が log の準備もする $ cd hello $ sudo cat << EOF | sudo tee run #!/usr/bin/env ruby # 自作スクリプト while true puts("hello ruby #{Time.now.to_i % 100}"); STDOUT.flush(); sleep(1); end EOF $ sudo cat << EOF | sudo tee log/run #!/bin/sh exec svlogd -ttt . EOF $ sudo chmod 755 run log/run $ tail -F log/current # ログが見られる。 $ sudo sv st . # daemon の状態を確認する。 run: .: (pid 35517 ) 46s; run: log: (pid 34727 ) 456s $ sudo sv st /service/hello/ # ディレクトリの指定方法は自由。 $ sudo sv t . # TERM シグナルを daemon に送る $ sudo sv st . run: .: (pid 35589 ) 1s; run: log: (pid 34727 ) 470s # 起動時間が 1s になってる。 まとめ 結局のところ、**「使えばわかるし使わないと便利さがよくわからない」**というのが正直なところです。 そのため、TechLunch においては、 使うための手順 を時間をかけて解説をするようにしました。 みなさんも興味があれば、ぜひ導入して使ってみてください。 僕自身、開発マシンである macbook pro に runit を入れて、開発環境の Ruby や MongoDB, Elasticsearch, Nginx などのサーバ群、 定期的に動かしたいちょっとしたスクリプトなどを runit で管理しています。 異なる設定のサーバ群を一つのマシンに同居させる場合も、設定ファイルを分けて別ポートで立ち上げたりしています。 以前のプロジェクトでは本番環境を runit で構築したこともありますし、今のプロジェクトでも、たまったゴミデータを削除し続けるスクリプトを runit で対応してそのまま放置(放置しても OK なくらいメンテナンスフリー)していたりします。 最近はクラウドやコンテナ技術が活況であり、環境を抽象化しようという流れがあります。しかしながら、そもそもプロセスや UNIX OS 自体が環境を抽象化するための技術群です。そういった基本的な技術と仲良くすることで、物事がシンプルになることがあるのではないかと考えたりしながら、日々開発に取り組んでいます。 お知らせ メドレーでは、医療介護の求人サイト「 ジョブメドレー 」、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」、オンライン診療アプリ「 CLINICS 」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております。

メドレー開発本部の nakatani です。 開発本部で定期的に開催している勉強会「TechLunch」で、 runit という unix のプロセススーパバイザについてお話しました。 その内容について紹介させていただきます。 runit 自体は特に目新しい技術ではなく(Linux の busybox に収められていたりする枯れた技術です)、大して難しい話題でもありません。 ただ、個人的には便利に使っている 手放せないツール であり、もしスーパバイザというものの存在を知らずに 使わずにいる人がいると勿体無いなあ という思いから、TechLunch のテーマとして取り上げた次第です。 runit とはなんなのか プロセスをデーモンとして立ち上げて、プロセスが死んでも再度起動し続けてくれるツール郡です。C 言語で開発されています。 Linux などの unix ではたいてい標準で init, Upstart, Systemd, launchd などのスーパバイザが組み込まれています。 runit はそれらと同じような位置づけのものです。 qmail の作者である djb が作った daemontools の後継のプロダクトです。 runit があると何が便利なのか ■ マシンが起動しているかぎり、プロセスを動作させ続けることができる マシンを立ち上げたあとに、起動コマンドを叩いたり、プロセスが落ちたときに再起動をする必要がありません。 また、フォアグラウンドで動作するプロセスを起動した後に、端末を切り離す操作をする必要もありません。 ただ、これは他のスーパバイザでも同じことが実現できます。 ■ その場しのぎで作ったスクリプトを、ほぼそのままデーモン化できる Shell, Ruby, Perl, Haskell どのような言語で作ったスクリプトであっても、 シェルなどで実行可能なファイルがあれば、それをそのままデーモンとして実行することができます 。 ■ スクリプトの標準出力をそのままログファイルとして扱うことができる svlogd というプログラムが、デーモンの標準出力をログ化し、ローテーションなどの面倒も見てくれます。 自作のデーモンが思った通りに動かない際のデバッグが容易です。 macOS への導入方法 macOS に導入するための手順を記載します。詳しくはスライドや runit のドキュメントなどを理解して使うようにしてください。 Xcode や Homebrew を macOS に導入していることが前提です。 /service を root の runit ディレクトリとして設定する手順 $ brew install runit # macports feels better. $ sudo mkdir /service $ sudo cat << EOF | sudo tee /Library/LaunchDaemons/runit.plist <?xml version='1.0' encoding='UTF-8'?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "https://www.apple.com/DTDs/PropertyList-1.0.dtd" > <plist version='1.0'> <dict> <key>Label</key><string>runit</string> <key>ProgramArguments</key> <array> <string>sh</string><string>-c</string> <string>PATH="/usr/local/sbin:/usr/local/bin: $PATH " exec '/usr/local/bin/runsvdir' '/service' </string> <string>;</string> <string>--pid=exec</string> </array> <key>Debug</key><false/><key>Disabled</key><true/><key>KeepAlive</key><true/> </dict> </plist> EOF $ launchctl load -w > /Library/LaunchDaemons/runit.plist $ launchctl list | grep runit 自作スクリプトをデーモンにする手順 $ cd /service/ $ sudo mkdir -p hello/log # log を同時につくると runsvdir が log の準備もする $ cd hello $ sudo cat << EOF | sudo tee run #!/usr/bin/env ruby # 自作スクリプト while true puts("hello ruby #{Time.now.to_i % 100}"); STDOUT.flush(); sleep(1); end EOF $ sudo cat << EOF | sudo tee log/run #!/bin/sh exec svlogd -ttt . EOF $ sudo chmod 755 run log/run $ tail -F log/current # ログが見られる。 $ sudo sv st . # daemon の状態を確認する。 run: .: (pid 35517 ) 46s; run: log: (pid 34727 ) 456s $ sudo sv st /service/hello/ # ディレクトリの指定方法は自由。 $ sudo sv t . # TERM シグナルを daemon に送る $ sudo sv st . run: .: (pid 35589 ) 1s; run: log: (pid 34727 ) 470s # 起動時間が 1s になってる。 まとめ 結局のところ、**「使えばわかるし使わないと便利さがよくわからない」**というのが正直なところです。 そのため、TechLunch においては、 使うための手順 を時間をかけて解説をするようにしました。 みなさんも興味があれば、ぜひ導入して使ってみてください。 僕自身、開発マシンである macbook pro に runit を入れて、開発環境の Ruby や MongoDB, Elasticsearch, Nginx などのサーバ群、 定期的に動かしたいちょっとしたスクリプトなどを runit で管理しています。 異なる設定のサーバ群を一つのマシンに同居させる場合も、設定ファイルを分けて別ポートで立ち上げたりしています。 以前のプロジェクトでは本番環境を runit で構築したこともありますし、今のプロジェクトでも、たまったゴミデータを削除し続けるスクリプトを runit で対応してそのまま放置(放置しても OK なくらいメンテナンスフリー)していたりします。 最近はクラウドやコンテナ技術が活況であり、環境を抽象化しようという流れがあります。しかしながら、そもそもプロセスや UNIX OS 自体が環境を抽象化するための技術群です。そういった基本的な技術と仲良くすることで、物事がシンプルになることがあるのではないかと考えたりしながら、日々開発に取り組んでいます。 お知らせ メドレーでは、医療介護の求人サイト「 ジョブメドレー 」、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」、オンライン診療アプリ「 CLINICS 」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております。

メドレー開発本部の nakatani です。 開発本部で定期的に開催している勉強会「TechLunch」で、 runit という unix のプロセススーパバイザについてお話しました。 その内容について紹介させていただきます。 runit 自体は特に目新しい技術ではなく(Linux の busybox に収められていたりする枯れた技術です)、大して難しい話題でもありません。 ただ、個人的には便利に使っている 手放せないツール であり、もしスーパバイザというものの存在を知らずに 使わずにいる人がいると勿体無いなあ という思いから、TechLunch のテーマとして取り上げた次第です。 runit とはなんなのか プロセスをデーモンとして立ち上げて、プロセスが死んでも再度起動し続けてくれるツール郡です。C 言語で開発されています。 Linux などの unix ではたいてい標準で init, Upstart, Systemd, launchd などのスーパバイザが組み込まれています。 runit はそれらと同じような位置づけのものです。 qmail の作者である djb が作った daemontools の後継のプロダクトです。 runit があると何が便利なのか ■ マシンが起動しているかぎり、プロセスを動作させ続けることができる マシンを立ち上げたあとに、起動コマンドを叩いたり、プロセスが落ちたときに再起動をする必要がありません。 また、フォアグラウンドで動作するプロセスを起動した後に、端末を切り離す操作をする必要もありません。 ただ、これは他のスーパバイザでも同じことが実現できます。 ■ その場しのぎで作ったスクリプトを、ほぼそのままデーモン化できる Shell, Ruby, Perl, Haskell どのような言語で作ったスクリプトであっても、 シェルなどで実行可能なファイルがあれば、それをそのままデーモンとして実行することができます 。 ■ スクリプトの標準出力をそのままログファイルとして扱うことができる svlogd というプログラムが、デーモンの標準出力をログ化し、ローテーションなどの面倒も見てくれます。 自作のデーモンが思った通りに動かない際のデバッグが容易です。 macOS への導入方法 macOS に導入するための手順を記載します。詳しくはスライドや runit のドキュメントなどを理解して使うようにしてください。 Xcode や Homebrew を macOS に導入していることが前提です。 /service を root の runit ディレクトリとして設定する手順 $ brew install runit # macports feels better. $ sudo mkdir /service $ sudo cat << EOF | sudo tee /Library/LaunchDaemons/runit.plist <?xml version='1.0' encoding='UTF-8'?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "https://www.apple.com/DTDs/PropertyList-1.0.dtd" > <plist version='1.0'> <dict> <key>Label</key><string>runit</string> <key>ProgramArguments</key> <array> <string>sh</string><string>-c</string> <string>PATH="/usr/local/sbin:/usr/local/bin: $PATH " exec '/usr/local/bin/runsvdir' '/service' </string> <string>;</string> <string>--pid=exec</string> </array> <key>Debug</key><false/><key>Disabled</key><true/><key>KeepAlive</key><true/> </dict> </plist> EOF $ launchctl load -w > /Library/LaunchDaemons/runit.plist $ launchctl list | grep runit 自作スクリプトをデーモンにする手順 $ cd /service/ $ sudo mkdir -p hello/log # log を同時につくると runsvdir が log の準備もする $ cd hello $ sudo cat << EOF | sudo tee run #!/usr/bin/env ruby # 自作スクリプト while true puts("hello ruby #{Time.now.to_i % 100}"); STDOUT.flush(); sleep(1); end EOF $ sudo cat << EOF | sudo tee log/run #!/bin/sh exec svlogd -ttt . EOF $ sudo chmod 755 run log/run $ tail -F log/current # ログが見られる。 $ sudo sv st . # daemon の状態を確認する。 run: .: (pid 35517 ) 46s; run: log: (pid 34727 ) 456s $ sudo sv st /service/hello/ # ディレクトリの指定方法は自由。 $ sudo sv t . # TERM シグナルを daemon に送る $ sudo sv st . run: .: (pid 35589 ) 1s; run: log: (pid 34727 ) 470s # 起動時間が 1s になってる。 まとめ 結局のところ、**「使えばわかるし使わないと便利さがよくわからない」**というのが正直なところです。 そのため、TechLunch においては、 使うための手順 を時間をかけて解説をするようにしました。 みなさんも興味があれば、ぜひ導入して使ってみてください。 僕自身、開発マシンである macbook pro に runit を入れて、開発環境の Ruby や MongoDB, Elasticsearch, Nginx などのサーバ群、 定期的に動かしたいちょっとしたスクリプトなどを runit で管理しています。 異なる設定のサーバ群を一つのマシンに同居させる場合も、設定ファイルを分けて別ポートで立ち上げたりしています。 以前のプロジェクトでは本番環境を runit で構築したこともありますし、今のプロジェクトでも、たまったゴミデータを削除し続けるスクリプトを runit で対応してそのまま放置(放置しても OK なくらいメンテナンスフリー)していたりします。 最近はクラウドやコンテナ技術が活況であり、環境を抽象化しようという流れがあります。しかしながら、そもそもプロセスや UNIX OS 自体が環境を抽象化するための技術群です。そういった基本的な技術と仲良くすることで、物事がシンプルになることがあるのではないかと考えたりしながら、日々開発に取り組んでいます。 お知らせ メドレーでは、医療介護の求人サイト「 ジョブメドレー 」、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」、オンライン診療アプリ「 CLINICS 」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております。

メドレー開発本部の nakatani です。 開発本部で定期的に開催している勉強会「TechLunch」で、 runit という unix のプロセススーパバイザについてお話しました。 その内容について紹介させていただきます。 runit 自体は特に目新しい技術ではなく(Linux の busybox に収められていたりする枯れた技術です)、大して難しい話題でもありません。 ただ、個人的には便利に使っている 手放せないツール であり、もしスーパバイザというものの存在を知らずに 使わずにいる人がいると勿体無いなあ という思いから、TechLunch のテーマとして取り上げた次第です。 runit とはなんなのか プロセスをデーモンとして立ち上げて、プロセスが死んでも再度起動し続けてくれるツール郡です。C 言語で開発されています。 Linux などの unix ではたいてい標準で init, Upstart, Systemd, launchd などのスーパバイザが組み込まれています。 runit はそれらと同じような位置づけのものです。 qmail の作者である djb が作った daemontools の後継のプロダクトです。 runit があると何が便利なのか ■ マシンが起動しているかぎり、プロセスを動作させ続けることができる マシンを立ち上げたあとに、起動コマンドを叩いたり、プロセスが落ちたときに再起動をする必要がありません。 また、フォアグラウンドで動作するプロセスを起動した後に、端末を切り離す操作をする必要もありません。 ただ、これは他のスーパバイザでも同じことが実現できます。 ■ その場しのぎで作ったスクリプトを、ほぼそのままデーモン化できる Shell, Ruby, Perl, Haskell どのような言語で作ったスクリプトであっても、 シェルなどで実行可能なファイルがあれば、それをそのままデーモンとして実行することができます 。 ■ スクリプトの標準出力をそのままログファイルとして扱うことができる svlogd というプログラムが、デーモンの標準出力をログ化し、ローテーションなどの面倒も見てくれます。 自作のデーモンが思った通りに動かない際のデバッグが容易です。 macOS への導入方法 macOS に導入するための手順を記載します。詳しくはスライドや runit のドキュメントなどを理解して使うようにしてください。 Xcode や Homebrew を macOS に導入していることが前提です。 /service を root の runit ディレクトリとして設定する手順 $ brew install runit # macports feels better. $ sudo mkdir /service $ sudo cat << EOF | sudo tee /Library/LaunchDaemons/runit.plist <?xml version='1.0' encoding='UTF-8'?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "https://www.apple.com/DTDs/PropertyList-1.0.dtd" > <plist version='1.0'> <dict> <key>Label</key><string>runit</string> <key>ProgramArguments</key> <array> <string>sh</string><string>-c</string> <string>PATH="/usr/local/sbin:/usr/local/bin: $PATH " exec '/usr/local/bin/runsvdir' '/service' </string> <string>;</string> <string>--pid=exec</string> </array> <key>Debug</key><false/><key>Disabled</key><true/><key>KeepAlive</key><true/> </dict> </plist> EOF $ launchctl load -w > /Library/LaunchDaemons/runit.plist $ launchctl list | grep runit 自作スクリプトをデーモンにする手順 $ cd /service/ $ sudo mkdir -p hello/log # log を同時につくると runsvdir が log の準備もする $ cd hello $ sudo cat << EOF | sudo tee run #!/usr/bin/env ruby # 自作スクリプト while true puts("hello ruby #{Time.now.to_i % 100}"); STDOUT.flush(); sleep(1); end EOF $ sudo cat << EOF | sudo tee log/run #!/bin/sh exec svlogd -ttt . EOF $ sudo chmod 755 run log/run $ tail -F log/current # ログが見られる。 $ sudo sv st . # daemon の状態を確認する。 run: .: (pid 35517 ) 46s; run: log: (pid 34727 ) 456s $ sudo sv st /service/hello/ # ディレクトリの指定方法は自由。 $ sudo sv t . # TERM シグナルを daemon に送る $ sudo sv st . run: .: (pid 35589 ) 1s; run: log: (pid 34727 ) 470s # 起動時間が 1s になってる。 まとめ 結局のところ、**「使えばわかるし使わないと便利さがよくわからない」**というのが正直なところです。 そのため、TechLunch においては、 使うための手順 を時間をかけて解説をするようにしました。 みなさんも興味があれば、ぜひ導入して使ってみてください。 僕自身、開発マシンである macbook pro に runit を入れて、開発環境の Ruby や MongoDB, Elasticsearch, Nginx などのサーバ群、 定期的に動かしたいちょっとしたスクリプトなどを runit で管理しています。 異なる設定のサーバ群を一つのマシンに同居させる場合も、設定ファイルを分けて別ポートで立ち上げたりしています。 以前のプロジェクトでは本番環境を runit で構築したこともありますし、今のプロジェクトでも、たまったゴミデータを削除し続けるスクリプトを runit で対応してそのまま放置(放置しても OK なくらいメンテナンスフリー)していたりします。 最近はクラウドやコンテナ技術が活況であり、環境を抽象化しようという流れがあります。しかしながら、そもそもプロセスや UNIX OS 自体が環境を抽象化するための技術群です。そういった基本的な技術と仲良くすることで、物事がシンプルになることがあるのではないかと考えたりしながら、日々開発に取り組んでいます。 お知らせ メドレーでは、医療介護の求人サイト「 ジョブメドレー 」、医師たちがつくるオンライン医療事典「 MEDLEY 」、口コミで探せる介護施設の検索サイト「 介護のほんね 」、オンライン診療アプリ「 CLINICS 」などのプロダクトを提供しています。これらのサービスの拡大を受けて、その成長を支えるエンジニア・デザイナーを募集しています。 メンバーのストーリー | 株式会社メドレー メンバーのストーリー 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp メドレーで一緒に医療体験を変えるプロダクト作りに関わりたい方のご連絡お待ちしております。

こんにちは！開発本部のエンジニア・ 新居 です。 メドレーは 9/18〜20 に開催された、 RubyKaigi 2017 の Ruby Sponsor を務めさせていただきました。（9/15〜17 に開催された iOSDC JAPAN 2017 に引き続きの協賛です！メドレーでは今年からテックカンファレンスへの協賛を積極的に行っています） イベント当日は、弊社から CTO の平山、エンジニアの平木と宍戸、そして新居の 4 人が参加しました。今回はそのときの様子などをレポートしたいと思います。 会場の様子 今年は広島県の広島国際会議場での開催でした。 広島国際会議場は平和記念公園の敷地内にあり、近くには原爆ドームや広島城などもあるので RubyKaigi のついでに観光しちゃおうなんて人も多かったのではないでしょうか。 会場の一角には今回の RubyKaigi 参加者がどこから来たかを掲示するボードが設置されていました。 日本以外からもたくさんの人が参加しており RubyKaigi の注目度の高さが伺えます。 そして隣にあったスポンサーボードの MEDLEY ロゴをしっかり確認して、CTO 平山とパシャリ！！！ ブースの様子 続いてブースの様子を！ ブースの仕上がりはこんな感じで、メドレーコーポレートカラーの赤が目立って良い感じでした！ 両サイドにはメドレーの事業概要と、メディアなどからも注目されることが多いオンライン診療アプリ「 CLINICS 」を紹介するポスターを配置、写真中央のモニターでは、スマートフォンや PC で医師の診療が受けられるという CLINICS のサービス概要がわかる紹介動画を流し、会社全体やプロダクトについて説明できる準備を整えました。 ノベルティは「MEDLEY ステッカー」「MEDLEY うちわ」「MEDLEY 絆創膏」の 3 種類を用意しました。 1 日目は台風一過で気温が上昇し、暑さをしのぐため MEDLEY うちわが大活躍してくれました！ MEDLEY 絆創膏はデザインのかわいさと医療系ならではということもありとても好評でした！参加者の中には靴擦れしている人や小さい擦り傷を負ってる人もいて、MEDLEY 絆創膏が参加者のお役に立てたのではないでしょうか。 ブース前で意気込む 3 人！ ちなみに T シャツはメドレー特製の バリュー T シャツ（左）とカレッジロゴ T シャツ（中央と右） を着用しています。 写真では見えませんが、バリュー T シャツにはメドレーのバリュー（行動規範）のひとつである「中央突破」の文字が入っています。 両 T シャツ共、目を留めてくれた参加者からはかわいいという声もいただけて、こちらも好評でした。 午後の 15:20~15:50 の Afternoon Break では大勢の参加者がブースゾーンに。 実際にブースに足を運んでいただいた参加者とお話していると、メドレーや CLINICS のことを知らない人がほとんどでしたが、メドレーが医療系のサービスを提供している会社であることや、CLINICS というオンライン診療アプリを開発していることをお話すると興味を持っていただけることが多かったように思います。 「今度病院で見かけたら使ってみます！」という声をいただいたり、参加者自身の医療体験を元に CLINICS というサービスについて意見を交わしたりと、メドレーエンジニアと参加者が密にコミュニケーションをとれる良い機会になりました。 大盛況です！ CTO 平山の発表 そして 3 日目の最後の Keynote 前には Ruby スポンサーの PR 枠があり、弊社の CTO 平山が発表しました。 発表では、「医療ヘルスケア分野の課題を解決する」というミッションのもとメドレーが 4 つの事業を行っていること、その中のひとつである CLINICS のプロダクトについて、「医療 x IT への挑戦」にむけて 医療従事者とエンジニア・デザイナーが協力してプロダクト開発を行う体制 などを紹介しました。 最終日 3 日目の最後ということもありお疲れの方も多かったと思いますが、会場を笑いで沸かすシーンもあり、メドレーと、そのプロダクトのことを少しでも多くの人に知っていただくとても良い機会になったのではないでしょうか。 当日の発表資料はこちらからどうぞ。 speakerdeck.com 周辺散策の様子（おまけ） 最後におまけということで周辺散策の様子を！ まずは原爆ドーム。 続いて広島城跡へ。御門橋。 歩みを進める 3 人。 そして天守閣。原爆で倒壊したためコンクリート建築として復元されたようです。 近くには広島護国神社。 メドレー 恒例 の？参拝！ 美味しい広島のお好み焼きもいただきました！ さいごに 今回はメドレーとして初の RubyKaigi 参加でした。 ブース運営などへの不安もありましたが、実際に当日を迎えてみると、参加者のみなさんとお話でき、メドレーのことを少しでも多くの人に認知していただくとても良い機会だったと思います。 まだまだメドレーのことをご存知ない方も多かったですが、実際にお会いして話してみると、医療というリアル産業をインターネットの力で変えていくという面白さに興味を持っていただけたことが多かったなという印象を受けました。 良いプロダクトを作ることも大切ですが、医療分野でのプロダクト作りの醍醐味や産み出せる価値などを多くのエンジニア・デザイナーに知ってもらえるよう、こうしたテックカンファレンスの場などで発信し続けていくことも大切だなあと改めて実感しました。 弊社で「医療 x IT への挑戦」に取り組みたいエンジニアのみなさんを心からお待ちしております！興味がある方は、こちらの「話を聞いてみたい」からご連絡ください。 www.wantedly.com 開発本部の雰囲気をもっと知りたい方は、こちらからどうぞ。 www.medley.jp