開発の現場ではビルドやテストを自動化して継続的に実行していく「継続的インテグレーション」（CI）が近年普及しつつある。CIを支援するためのツールはいくつかあるが、今回はGitHubと連動し、指定したリポジトリ上にあるコードを自動的に取得してビルドやテストを実行できるサービス「Travis CI」を紹介する。 Travis CIで手軽に継続的インテグレーションを導入 「継続的インテグレーション（CI）」とは、ソフトウェア開発過程において頻繁にテストを行うことで問題を早期に発見し、品質の向上を図る開発手法である。しかし、テストを毎回手動で行うのには手間がかかる。そこで特定のタイミングで自動的にテストを実行し、テスト完了後にその結果を通知する「CIツール」などが利用される。 CIツールとしてよく知られているものとして「Jenkins」などがあるが、多くのツールでは独自にテストのための環境を構築し
やった事をまとめると、以下の通り。 StackでHaskellのパッケージ(Hakyll)を管理する。 markdownでブログを書き、Hakyllでhtmlファイルに変換する。 実際には、TravisがHakyllを使ってコンパイルしhtmlファイルに変換する。 ソースファイルはGithubの公開リポジトリで管理し、Github Pagesで公開する。 できたのが本ブログ。 Stack Stackは、 Haskellのパッケージをビルドしたりインストールしたりするツールです。 tanakhさんによる 紹介記事をきっかけに知りました。 Haskell力のない自分にはcabal hellを乗り越えられる自信が無かったという理由と、 タイムリーなので使ってみたいという理由から選択してみました。 Hakyll Hakyllは、 Haskellによる静的htmlページ生成ツールです。 Rubyによ
骨折しました。@kyo_agoです。 今日はTravisCI上で実ブラウザ環境のテストを行う方法を紹介したいと思います。 弊社ではこれまで実ブラウザ環境のテストではTravisCIからProtractorを使ってSauceLabsへ接続してテストを行っていました。 しかし、これには以下のような問題があったため、ProtractorとSauceLabsを使用しない構成へ移行しました。 テストが高頻度で失敗するテストに影響しない部分の修正ですらテストが失敗し、コードの修正よりテストを通すほうが難しい状況になっていました。 （これは社内では「e2eガチャ」と呼ばれ、レビュー依頼のコメントには「e2eガチャ 1/5」と成功率が書かれていました。ちなみに「1/5」はわりといい確率です。悪い時は「1/12」くらいになります） 遅いSauceLabsへの接続時間、WebDriver経由のテスト実行などは
2023年1月1日 2022年の振り返り 今年は良くも悪くも某国際球技イベントに振り回された年だった。 2022年11月23日 eslint-plugin-importによってVitestの設定ファイル上でエラーが発生する場合がある vitest と eslint-plugin-import に依存している環境では、vitest.config.ts内で vitest/config をインポートすると Unable to resolve path to module 'vitest/config'. eslint(import/no-unresolved) というエラーが出る場合があります。 2022年8月24日 Next.js + Vercel + microCMSなどを使ってほぼ無料でブログを運用する 当ブログのシステム構成について紹介します。構成を真似することでほぼ無料（後述）でブログ
I’m excited to announce the first release of LambCI, an open-source continuous integration tool built on AWS Lambda 🎉 LambCI is a tool I began building over a year ago to run tests on our pull requests and branches at Uniqlo Mobile. Inspired at the inaugural ServerlessConf a few weeks ago, I recently put some work into hammering it into shape for public consumption. It was borne of a dissatisfact
概要 こんにちは。本日の担当の@hiro_kobaです。リブセンスでアクセスログ分析基盤の開発等をやっております。 本日は最近人気のある5個のCIツールを、色んな角度から比較してみようと思います。 背景 テスト環境でテストを実行し、通ったらステージングにデプロイ、その後動作が確認できたら本番デプロイ。 日々のオペレーションでよくある光景かと思いますが、手動での手順が多いためミスが発生しやすく、かつ手間も掛かるため、課題を感じておりました。 これらの継続的な運用フローを自動化してくれる仕組みとして、CIツールがあります。 CIツールは大きく分けて、以下3つに分類されるようです。参考 Everything（全方位型） Build, Test and Delivery（ビルド・テスト・デプロイ特化型） Specialization（その他特化型） 今回の問題には「Build, Test and
マトリックステストとは？ マトリックステストの行い方 実行結果 問題点 軸の設定をジョブにハードコーディングする必要がある 除外設定が面倒 俺はTravis CIみたいにリポジトリにコミットしたymlファイルでテストしたいんじゃああああああ！！！１１１１１ 使い方 マトリックステストとは？ 複数のパラメータを掛けあわせてテストを実行することです （例：Ruby 2.1系、2.2系、2.3系 x Rails 4.2系、5.0系 = 計6パターンのテストを行うこと） Travis CIの方がもっと手軽に行う事ができるのでOSS開発の場合はそっちを使うといいと思います 参考 sue445.hatenablog.com マトリックステストの行い方 「新規ジョブ作成」で「マルチ構成プロジェクトのビルド」でプロジェクトを作成します 「マトリックスの設定」でテストしたい軸とパラメータを記述するだけです
こんにちは。 @suzu_v です。 Advent Calendar 2015 18日目 休載のお知らせ - VOYAGE GROUP techlog とのことだったので代打で書いてみます。*1 いま私が所属している fluct ではCIの一部にTravis CIを利用しています。用途としては、 継続的なテスト 継続的なビルド というところを担当しています。今日は簡単に、 Uploading Artifacts on Travis CI - Travis CI travis-ci/artifacts の紹介をします。 Travis Artifacts travis-ci/artifacts はTravis CIのアドオンとして利用されているもので、ビルド済みのartifactsを扱うことができます。私たちは一部のバッチやAPIサーバの実装について、Travis CIを利用したビルド及びs3
いまさら感もあるのだけど、あまり知られていないようなのでTravis CIの高速化+αなtipsを書いておく。 先にNode.js向けの完成形の.travis.ymlはこちら。 language: node_js node_js: - "0.12" - "4" - "6" sudo: false cache: directories: - node_modules Tipsは3つ。 テスト対象のNode.jsバージョンを指定する sudo: false: コンテナベースの環境を使う cache: 依存パッケージをキャッシュする テスト対象のNode.js/io.jsのバージョンを指定する 最近はカジュアルにio.jsを使う人/プロジェクトが増えてきている（要出典）ので、特に政治的な理由でもなければnpmパッケージのテストはNode.jsとio.jsの両方で流しておくのが良いと思う。.tra
Travis CIが出た時から、当社はビルドにおける安定性と信頼性の提供を第一にしてきました。しかし、常に期待に応えてこられたとは言えません。ネットワークの問題や、ビルドのキャパシティが不十分で(オープンソースプロジェクトに対して)ビルド開始までに時間がかかる、ビルド環境におけるCPUやメモリのリソースに制限がある、オープンソースプロジェクトに対応するキャッシュがないなどの問題がありました。また、現在当社で使っている大部分のLinuxのスタックはプライベートクラウド上で動作するため、要求してからキャパシティに空きができるのを待つというプロセスを経なければならなりませんでした。そのため、キャパシティを増やすという課題もありました。 今回ご紹介するのは、このような課題に対応した新たなビルド・インフラストラクチャです。これからは、プライベートやオープンソースのリポジトリにもお使いいただけます。
CI サービスをいくつか触ってみたのでまとめ。 今回の目的は、テストを実行すること。なので、ビルドやデプロイ辺りはちゃんとは見ていない。 ドキュメントで確認しただけの項目などもあったりするので、間違っていたらごめんなさい。教えてもらえると助かります。 ただ、これは記事を書いた時点での比較で、今後のサービスの変更に対応する予定はないです。 触ってみたサービス一覧 アルファベット順。 AppVeyor CircleCI Drone IO Magnum CI semaphore shippable Travis CI wercker codeship ってのもあったけど、無料プランは月100ビルドまでとかで常用には耐えないと感じたので中身見てない。 機能比較 機能比較は全て無料プランでのもの。有料だと対応している場合でもここでは x にしている。 比較項目は私の独断と偏見で適当に選出した。 項目
日本の祝日はいろいろ判定が難しいらしいですが、皆さんどうしていますか？ @k1LoW @shin1x1 日本の祝日は世界でも珍しい部類の天文ベース（春分の日、秋分の日）になっていて厳密には前年度の４月？とかに国が発表するのでGoogleも１年以上先はわからないんですよね。天文ベースプラス人の微調整で決まるそうで。— Masaki Komagata (@komagata) 2014, 11月 12 「国民の祝日」について Rubyでは komagata/holiday_jp がメンテナンスされているそうで羨ましいかぎりです。 PHPでもJavaScriptでも、こういう「メンテされている祝日判定ライブラリが欲しい！」と思ったので、この際なので d:id:tagomoris さんがはじめた woothee プロジェクト を見習って、まずは祝日を共有するためのデータセットを作ってみました。 k1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
