最近はTravisCIとかCircleCIとか便利なCIサービスが増えているみたい。 いまぼくがつくってるGIFMAGAZINEでもCIサービスを利用してみようと思って、色々調べてたらwerckerというサービスが良さそう。 werckerは、 github/bitbucket対応 privateリポジトリにも対応 無料(ベータ版なのでいつ有料になるかわかりません) という特徴があります。 今回のケースでは、bitbucketのprivateリポジトリが使えて、手頃なお値段で安ければよかったのでwerckerを採用しました。 werckerを使うと、bitbucketのプライベートリポジトリ(0円)+wercker(0円)で最高に懐に優しい開発+CI環境ができます。 ではその手順。 前提 以下については事前に準備済みとします。 bitbucketへのユーザー登録 プライベートリポジトリの作
2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。本件に関する詳細は、プレスリリースをご確認ください。 2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。 本件に関する詳細は、プレスリリースをご確認ください。
こちらの記事について、最新のTravis CIの環境(2014/4/15)ではコード署名に失敗する問題があります。 その問題の修正については下記の記事にまとめました。 Travis CIでipaを作るときのCode Signが失敗するのを修正したメモ - 24/7 twenty-four seven 実際は完全に移行したわけではなくて、Travis CIの有料プラン(プライベートリポジトリが使える)のフリートライアルを試しているところなのですが、しばらくはTravis CIでCIを動かすことにしたので、そのときの設定などをまとめます。 もともとは社内のサーバでJenkinsをホストしていて、それがダメということは全然ないのですが、社内でサーバをメンテナンスするのも面倒だし、ビルドスクリプトとかをポータブルな状態にしておくのは手元でサクッと実行できたりいろいろ都合が良さそうだと思い、試しにや
CIって? CIはContinuous Integration(継続的インテグレーション)の略です。 継続的インテグレーションとは、ソフトウェア開発手法において、プロジェクトメンバーがそれぞれ開発した結果を頻繁に結合し、定期的にビルドやテストを行うことである。問題点を早期に摘出することができ、効率的な開発に役立つ。 不具合は早く見つける方が対策費用が抑えられるため、ソフトウェアのビルドを頻繁に行うのが好ましく、ビルド結果が正しいことを検証するためにすぐにテストを行う。このような手続きは出来る限り自動化するのが好ましい。そのため、継続的インテグレーションを実践するためには、結合のためのビルドとテストの自動化のために「CIサーバー」などと呼ばれる専用コンピュータを用意することが推奨されている。 ちなみに、ソフトウェア開発手法のひとつである「エクストリームプログラミング」では、継続的インテグレー
SaaSのCIと言えばTravis CIやCircle CIといったサービスが有名ですが、いずれにしてもプライベートリポジトリを使う場合は有料なのです。しょうがないよね、商売だもんね。でもCI入れたいなぁ。 そんな中、GithubだろうがBitbucketだろうがプライベートリポジトリでも無料で使っていいよ!というβ期間中のCI、Werckerが僕の周辺で話題になっていたので、触ってみました。画面もスゲー使いやすい上に、ハマりどころもなく、これはひょっとしてひょっとするんじゃないの?という期待を込めて、rails newからRailsアプリをHerokuにデプロイするまえのチュートリアルを作ってみました。みなさんもこの記事を参考に、ぜひ使ってみてください。 この記事のゴール Githubにpushしたら自動的にWercker上でRSpecのテストが動くこと Werckerでのテストに成功し
先日プレスリリースが出たのですが、KAIZEN platform という会社で技術顧問などをやっています。それから、一昨日自分も出たWebアプリケーション開発に関する勉強会 (資料) を開いたじげんという会社でも少し前から同じように顧問のような形で携わっています。 自分が関わっている会社のPRも含めて、すこし、2013年現在のWebサービス開発の現場感、やり方みたいなものを書いてみたいと思う。ただ、自分の利益があるところの話だけではフェアではないので、Webエンジニアならよく知っているであろう Qiita を運営しているインクリメンツの様子も合わせて紹介する。 KAIZEN platform KAIZEN platform が提供しているサービスは planBCD という A/B テストの SaaS で、Webサイトのコンバージョンだとかを画面の構成要素を変えて効果測定したいとか、そういう
Continuous Integration Integrate and deploy your applications
https://github.com/gfx/App-test-travis Travis-CI は CPAN Testers のない言語だとライフチェンジングなサービスだし、 CPAN Testers のある Perl においてもpushごとにCIを走らせたりちょっと変わった設定でテストを走らせたりできる大変便利なサービスですが、設定ファイルを正しく書くのがわりと面倒で、うまく動かすために.travis.ymlを少し変更してcommit & pushというのを何度もするはめになったりします。なので、ローカルで.travis.ymlを読んで実行するコマンドがあれば便利だろうというのがこれを作った動機です。 まだ作りはかなり適当で、before_install, install, before_script, scriptセクションを順番に実行するだけのもので、envやversionsをよし
『JUnit実践入門』写経・実践会 in 横浜 #7 のハンズオン用。 このエントリではJava(Groovy)について書いていますが他言語でもだいたい同じです。 前準備 : MavenかGradleでテストできる状態にあるプログラムをGithubに公開する 1 : Travis CIにアクセスする https://travis-ci.org/ の右上からGithubアカウントでログイン 2 : 自分の名前→Accountsでリポジトリの一覧が出る 3 : スイッチをOFFからONに切り替える Github側も勝手に連携される Tokenも全部設定されてるSUGEEEEEEEEEE!!!!!!!!!!1111111111 4: リポジトリのルートに設定ファイル( .travis.yml )を置く Java language: java jdk: - openjdk6 - openjdk7
技術部の福森です。 クックパッドでは RSpec と Jenkins を利用して CI による自動テストを行なっています。 テストの数は 12000 examples を越えていて、テストによっては稀に失敗する物が出てきています: 時間帯依存で失敗してしまうもの 他に同時に実行されるテストに依存しているもの (並列実行で組合せが変わり再現する) インテグレーションテストでの ajax リクエストの微妙なタイムアウト etc また、本番環境を壊さないよう、 CI で成功したリビジョンのみデプロイ可能となっており、開発者が push しデプロイしたいと思っている時に無関係な原因で失敗する事を避けたいという欲求があります。 なぜなら、再度ビルドを実行する時間 (およそ 10 分) の間待たされる事になるからです。 そこで、そのようなテスト起因での失敗を減らし、かつ開発者にそれらを修正してもらうた
Sometimes developers don’t implement the Test Driven Development (TDD) methodology just because the project they are building is small and does not need testing frameworks. But, this is a fatal… Routing in web applications allows for seamless navigation, ensuring users effortlessly access different pages and resources within an application. As such, when implemented correctly, routing offers an in
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く