継続インテグレーションは強みではなくなった: 柴田 芳樹 (Yoshiki Shibata)
Subversion/Gitなどを使用したソースコード管理、Jenkinsを使用した継続的インテグレーション、様々なxUnitフレームワークを使用した自動テストなどをソフトウェア開発組織として実践することは、今日では、その開発組織の技術的な強みではありません。 それらを実践しないことが、ソフトウェア開発組織の「弱み」なのです。また、組織としてそれらの実践を推進しない、あるいはサポートできないマネージャも「弱み」となります。さらに、大規模なソフトウェア開発組織においては、それらのためのインフラ整備をプロジェクトごとに立ち上げなければならず、サポート部門が存在しないことも弱みとなります。※1 ※1 プロジェクトを始めるごとに、ソースコード管理やJenkins用のサーバの調達、OSから様々なツールのインストールを一通り行うためには、それなりの時間を要します。したがって、バックアップをも含めて環境
CI 用 Docker イメージ作成におけるベストプラクティス
H2O の CI では長らく、秘伝のタレ的な .travis.yml を使い続けてきたのですが、なにぶん依存関係が多いもので、だいぶメンテナンスが辛い感じになってきていました。また、CI テストで発生したエラーの調査の度に、時間のかかる CI を回さなければならないことが、開発者のストレスとなっていました。 そこで一念発起して、Docker イメージを使った CI に切り替えることにしました（実行環境としては引き続き Travis を使います）。 その際に、要件として以下のようなことを考えました。 CI以外に、コミット前のテストにも使えるようなイメージにすること コマンド一発でビルドとテストが動作すること 無駄な処理をしないこと その結果、以下のような実装になりました。 テストに必要なソフトウェア群をインストールしたイメージを Docker Hub にアップロードしておく テストには、1.
AWS CodeBuild ― フルマネージドのビルドサービス | Amazon Web Services
Amazon Web Services ブログ AWS CodeBuild ― フルマネージドのビルドサービス 開発者は通常、ソースコードの変更に対する継続的インテグレーションのビルドとテストを実行するために、共有のビルドサーバを構築し運用しなければいけません。継続的インテグレーションを運用するのは面倒なことなので、多くの開発者はそれを避けてローカルマシンでビルドを実行します。これによって、ある開発者の環境では動作するコードが最終的な本番環境ビルドで動作しないという状況が、しばしば引き起こされます。 多くの開発チームは、CI/CD（継続的インテグレーション / 継続的デプロイ）パイプラインの構成要素としてビルドファームを構築します。ビルドファームの構築と運用はコストが高く、また独特のスキルが求められます。普段はビルドファームはあまり使われていませんが、修羅場の時には利用率は100%に達し、
knife-soloをアップデートしたらdockerを使ったサーバCIに失敗した - tjinjin's blog
About dockerを使ったサーバCI（dockerの使い方としていいか悪いかは別として）をしていますが、最近knife-soloをアップデートしたタイミングでCIがコケるようになりました。原因調査したので、備忘録として残しておきます。 概要 CircleCIを使ってdockerコンテナを2台起動し、その2台に対してcookしています。 github.com $ cat circle.yml machine: timezone: Asia/Tokyo services: - docker checkout: post: - git submodule sync - git submodule update --init # use submodules dependencies: cache_directories: - "~/cache" pre: - cp ./.ssh/ssh-c
Dokumi (日本語) - クックパッド開発者ブログ
(English version here) 技術部モバイル基盤グループのヴァンサン(@vincentisambart)です。今日は最近作ったツール「Dokumi」の話をしようと思います。 紹介 他部署のエンジニアの仕事をもっと楽にすることが、技術部の重要な目的の1つです。その中で、Dokumiはモバイル開発者のコードレビューの負荷を減らすためのツールです。 なぜ「毒味」という名前にしたかと言うと、人間がレビューする前に、コードに毒(バグ、不自然なコードなど)が入っているかどうか毒味するツールだからです。別の言葉で言うと、少し進化したCI用のlintツールですね。pull requestが出る度に、Jenkinsがそのpull requestにDokumiをかけます。現在はDokumiはiOSアプリだけに対応してしていますが、今後はAndroidアプリへの対応も考えています。 現時点でDo
Tachikoma.io を使ってみた - えいのうにっき
Tachikoma.io とは Dependency Update as a Service 、例えば bundle update だとかの定形作業を自動でやってくれるサービスを SaaS として提供してくれているもの。弊社の技術ブログ は Middleman で動いているんだけど、それの bundle update もつい先日、この Tachikoma.io で Automatically になったりして、自分の周辺ではちょっとしたブームになってたりする（遅い）。 上記 Middleman への Tachikoma.io の適用は、他の仕事もあったりして自分の手ではできなかったので、適当な自分の public repository に対して Tachikoma.io の設定をやってみた。 まずは Tachikoma.io にサインアップ GitHub アカウントで。 そして Author
開発者向けサービスのビジネスが成功する時代に - cakephperの日記(CakePHP, Laravel, PHP)
CircleCIのブログに、「Developers Matter: New Relic IPOs」という記事がありました。 2011年当時、投資家から開発者向けのサービスで稼ぐのは難しいと言われたが、最近はNewRelicのIPOもあって、開発者向けのツールやサービスが注目されるようになった。これはまだ始まりであって、CircleCIのようなサービスがどんどん出てきてビジネスとして成功していくだろう、とのこと。 必要なものは自分たちで買って構築して運用してというスタイルから、良いツールをうまく運用してくれるサービスを使って組み合わせる時代になってきました。やはり、メインビジネス以外のところを自前主義でがんばったとしても効果は限定的ですし、運用コストもかかるし、時代の流れについて行くのが難しくなってきているからでしょう。 私が関わっている継続的セキュリティテストサービスVAddyも同じ開発者
CircleCIでDockerコンテナに対してansibleを実行しserverspecでテストをする · さよならインターネット
November 13, 2014 参考 KAIZEN platform Inc. における運用自動化 - Speaker Deck Continous Integration and Delivery with Docker - CircleCI TL;DR CircleCI上でDockerコンテナを立て、 そのコンテナに対してプロビジョニングを行い、 プロビジョニング後のコンテナに対してテストを行う DockerコンテナにAnsibleを実行する コミットする度にDockerのimageをpullするのは時間がもったいないので cache_directoriesを利用し、imageをexportしておき 実行時にimportするようにすると多少速くなる。 . ├── Dockerfile ├── ansible/ └── circle.yml Dockerfile FROM kenji
Googleのテスト自動化の進化 - ワザノバ | wazanova
https://www.youtube.com/watch?v=6ZvCU0dht50 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 Google Test Automation Conferenceが今年はSeattleで開催されたようです。その中で興味深いと感じた話題をいくつか拾ってみました。 1) 成長を続けるGoogle 会社の規模が大きくなり、歴史を重ねてくると、何事も非効率になりがちですが、Ankit Mehtaが紹介してくれた数字によると、Googleの開発ペースは依然として右肩あがりのようです。 コードのコミットは、1日3万チェックイン。約3秒に1回。グラフを目測した限りでは昨年から約20%増。 リリース数もこの1年でほぼ倍増。 2) テストクローラーを利用してのモバイル実機テストの
名前を付けること、生命を吹き込むこと - cakephperの日記(CakePHP, Laravel, PHP)
最近リリースした継続的セキュリティスキャンサービスVAddy(バディ)の話です。 http://vaddy.net VAddyのプロモーション動画はこちら。 1年前ぐらいにVAddyのざっくりしたコンセプトはあって、 どの方向で行くべきか、どのような世界を目指すべきかという議論を散々やってました。 まだその頃には名前がなくて、security, scan, test, Continuousなどの文字から何かサービス名を考えていました。 でも全然しっくりくる名前が出なくて2ヶ月ぐらいしたころには、とりあえず住んでる地名(Chihaya)でも良いんじゃない？とか冗談がでる始末。 2ヶ月ずっと考えていた末に出たのが、VAddyでした。 Vulnerability Assessment is your Buddy(脆弱性診断はあなたの相棒）の省略形です。 VAddyの言葉が浮かんだ時はすごく興奮し
GitHub と CI を連携してる人にオススメの userscript: PR Build Status in Favicon - 詩と創作・思索のひろば
GitHub を使って Pull Request ベースで仕事しているとこんなことがありますよね…… ( ^o^) LGTM もらった！:sushi: ( ˘⊖˘) 。o(CI 通ったらマージしよう) |花金|┗(☋｀ )┓三 ( ◠‿◠ )☛ マージしてから帰れよ ▂▅▇█▓▒░(’ω’)░▒▓█▇▅▂ 忘れてたああああああ Issue/PR のタブを開きすぎて、自分のにしろ他人のにしろ何がどこにあってステータスがわからなくなってしまうという問題もありますね。 そんなときに便利なユーザースクリプトがこちら。 GitHub PR Build Status in Favicon chrome://extensions に放り込むなどしてインストールすると、ビルドステータスが設定されている Pull Request（例）では、Favicon の右下にそのステータス（最新コミットのもの）を表す色
rubocopによる静的コード解析でRubyのコード品質を保つ | Act as Professional
rubocopはRubyの静的コード解析ツールです。このコード解析を通すことによって、一定のRubyの書き方に統一することができます。また、不要な変数やメソッド名が長すぎるなど、一般的にRubyとして読みやすいコードにするための警告もされます。 こういった警告はRuby coding style and best practicesとしてRuby coding style guideにまとめられおり、Rubyを書くのであれば基本的にはRuby coding style guideを一読しておくことをおすすめします。英語が苦手であれば、翻訳された日本語版も存在します。 なぜ静的コード解析をするのか？静的コード解析し一定の読みやすいコードに統一することによって、人間が誤読する確率を下げることにより、バグなどの混入させる確率を下げる効果があります。また昨今ではGitHubでコードレビューをするよ
Emacsのバージョンマネージャ "evm" がEmacs LispのCIにおすすめ - Copy/Cut/Paste/Hatena
RubyのrbenvやPHPのphpenvと同じように、Emacsにもバージョンマネージャがあります。 まあ、だいたいの人は最新のEmacsをエディタとして、もしくは環境として利用していると思いますので、普通のEmacsユーザにはあまり必要ないかもしれません。 ただ、Emacs LispをCIにかけるときに真価を発揮します。そうです、EmacsはEmacs Lispの実行環境でしたね。 なのでEmacsにもバージョンマネージャが必要になります。そうです。必要です。 evm https://github.com/rejeep/evm evmはf.elでも有名なrejeepさんがメンテナンスをしています。 使い方は、 evm install [version] でバージョンを指定してインストールする evm use [version] で指定のバージョンのEmacsを使う と、RVMに似ていま
CI（継続的インテグレーション）サービスまとめ・14個！ - atskimura-memo
CIって？ CIはContinuous Integration（継続的インテグレーション）の略です。 継続的インテグレーションとは、ソフトウェア開発手法において、プロジェクトメンバーがそれぞれ開発した結果を頻繁に結合し、定期的にビルドやテストを行うことである。問題点を早期に摘出することができ、効率的な開発に役立つ。 不具合は早く見つける方が対策費用が抑えられるため、ソフトウェアのビルドを頻繁に行うのが好ましく、ビルド結果が正しいことを検証するためにすぐにテストを行う。このような手続きは出来る限り自動化するのが好ましい。そのため、継続的インテグレーションを実践するためには、結合のためのビルドとテストの自動化のために「CIサーバー」などと呼ばれる専用コンピュータを用意することが推奨されている。 ちなみに、ソフトウェア開発手法のひとつである「エクストリームプログラミング」では、継続的インテグレー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Docker時代の分散RSpec環境の作り方 // Speaker Deck
New GitHub Organization API and deppbot · Issue #11 · jollygoodcode/jollygoodcode.github.io
http://blog.inouetakuya.info/entry/2014/10/05/130801
Dependency Update as a Service - Tachikoma.io
Pull Request ベースのインフラ運用と Cookbook CI