Bazel とお別れして make を使いはじめた話
こんにちは。MIXI 開発本部 SREグループの riddle です。 自分の所属するプロダクトでは、ビルドツールとして Bazel を利用していたのですが、いろいろあって make に変えたので「Bazel をなぜ導入してなぜやめたのか？」 を紹介します。 ＜目次＞ Bazel とはどこに Bazel を使ってたのか？なぜ Bazel をやめたのか？ 3-1. Bazel の運用コストが高かった 3-2. Bazel の速度問題 3-3. Bazel ではできないことがあるmake に移動したわけまとめBazel とは Bazel は Google が開発したビルドツールで、Java、C++、Go、Android、iOS、その他多くの言語とプラットフォームを使用してビルドとテストができます。 ローカルやリモートのキャッシュをうまく用い、アプリケーションのビルドやコンテナイメージの生成、テ
git-pr-releaseのすすめ - ninjinkun's diary
Github (含むEnterprise) で開発をしているなら、Github Kaigiでも紹介されていた git-pr-release が便利です。自分の会社ではアプリのリリース前にQAを実施しているのですが、QAを始める前にどの機能がリリースされるのかをリストアップし、それをGoogleスプレッドシートに入力する作業が繁雑でした。 git-pr-release を使うと、これをリリースPull Requestに集約して自動化することができます。リリースPull Requestとは以下のようなものです (スクショはこのツールのPR用に作ったダミー)。 具体的なリリースまでの作業手順は以下のようになります。 開発ブランチにリリースする機能のPull Requestをmergeしていく git-pr-release を実行 merge済みのPull Requestの情報を集めてチェックリス
ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習
最近、あまりプログラミングが得意でない人のサポートをする形で、長い時間にわたってペアプログラミングを行っている。そのなかで、気がついた悪い習慣と成長するための良い習慣というものをまとめてみる。 この記事のバックグラウンドとなる体系的知識が本になりました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング あわせて読みたい 経営者マインドが足りない！vs. 現場に任せてくれない！の対立をなくすカードゲームをつくった話 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ 心理的安全性ガイドライン（あるいは権威勾配に関する一
CI（継続的インテグレーション）サービスまとめ・14個！ - atskimura-memo
CIって？ CIはContinuous Integration（継続的インテグレーション）の略です。 継続的インテグレーションとは、ソフトウェア開発手法において、プロジェクトメンバーがそれぞれ開発した結果を頻繁に結合し、定期的にビルドやテストを行うことである。問題点を早期に摘出することができ、効率的な開発に役立つ。 不具合は早く見つける方が対策費用が抑えられるため、ソフトウェアのビルドを頻繁に行うのが好ましく、ビルド結果が正しいことを検証するためにすぐにテストを行う。このような手続きは出来る限り自動化するのが好ましい。そのため、継続的インテグレーションを実践するためには、結合のためのビルドとテストの自動化のために「CIサーバー」などと呼ばれる専用コンピュータを用意することが推奨されている。 ちなみに、ソフトウェア開発手法のひとつである「エクストリームプログラミング」では、継続的インテグレー
Githubのプライベートリポジトリでも無料で使えるCI、Werckerを使ってrails newからHerokuのデプロイまでやってみる | mah365
SaaSのCIと言えばTravis CIやCircle CIといったサービスが有名ですが、いずれにしてもプライベートリポジトリを使う場合は有料なのです。しょうがないよね、商売だもんね。でもCI入れたいなぁ。 そんな中、GithubだろうがBitbucketだろうがプライベートリポジトリでも無料で使っていいよ！というβ期間中のCI、Werckerが僕の周辺で話題になっていたので、触ってみました。画面もスゲー使いやすい上に、ハマりどころもなく、これはひょっとしてひょっとするんじゃないの？という期待を込めて、rails newからRailsアプリをHerokuにデプロイするまえのチュートリアルを作ってみました。みなさんもこの記事を参考に、ぜひ使ってみてください。 この記事のゴール Githubにpushしたら自動的にWercker上でRSpecのテストが動くこと Werckerでのテストに成功し
状態ではなく、振る舞いをモックせよ
TL;DR GOOS本『実践テスト駆動開発』で触れられている「ロールをモックせよ」について、違った角度で解説ドメインモデルを豊かにすることでコードがシンプルになる例Mock Behaviors, Not Statesユニットテストを記述する際、テスト対象のオブジェクトが利用しているオブジェクト（依存オブジェクト、隣接オブジェクト）はモックオブジェクトにして、テストしたい状況をテストコード側からコントロールします。しかし、闇雲にモックを使ってテストを記述すれば良いわけではありません。今回は、モックが有効に機能するテストとはどういったものなのかを解説します。 サンプルコード簡単なサンプルで説明します。Extract Till You Dropのモデルと近いものを使います。グループ、メンバー、およびグループリポジトリがあります。グループオブジェクトはインメモリでは所属メンバーの情報を保持しておら
JavaScript - QUnitでBDD風に書いたりCIするために調べたこと - ぼっち勉強会
調べたこと QUnit テスト関数を入れ子にしたい pavlov / specit(BDD風にテストを階層化) sinonjs(モックライブラリ) phantomjs(コマンドライン実行) travis連携の仕方 kannokanno/qunit-example QUnit 基本的な使い方 インストール 非UIテスト(純粋なロジックテスト) UI(DOM)テスト 非同期テスト あたりはググればいっぱい情報出てくるので割愛。 サンプルコードは一応リポジトリにはある。 テスト関数を入れ子にしたい QUnitで一番困るというか、好みじゃない点です。 例えばこういうプロダクトコードがあるとします。 var Calc = (function(){ function Calc() { } Calc.prototype.add = function(x, y) { return x + y; } Cal
Jenkins がもっともっともっと便利になるプラグイン 8 つ
こんにちは、開発担当の松本です。 前々回、 前回に引き続いて、 今回も Jenkins の便利プラグインをいくつか紹介します。 リストビューの表示内容を拡張する: Extra Columns 名前や上の画像が示すように、リストビューに表示するカラム項目を拡張してくれるプラグインです。 プラグインインストール後に、ビューの変更のカラムに上記画像のような項目が追加されています。項目によっては設定も付いていたりします。 プロジェクト説明や設定へのリンクなど小粋で便利なカラムが多いので入れておくと便利です。 リストビューをグループ化できる: Categorized Jobs View 正規表現を用いたグループによって、リストビューの項目をまとめることができるプラグインです。 カテゴリビューを作成するには、プラグインをインストールした後に、新規ビュー作成ページで「Categorized Jobs V
Etsy Engineering | LXC - Running 14,000 tests per day and beyond! (Part 1)
Continuous Integration at Etsy As Etsy continues to grow and hire more developers, we have faced the continuous integration scaling challenge of how to execute multiple concurrent test suites without slowing the pace of our deploy queue. With a deployment rate of up to 65 deploys / day and a total of 30 test suites (unit tests, integration tests, functional tests, smokers...) that run for every de
CIのビルド結果をChromeで受け取る·BuildReactor MOONGIFT
BuildReactorはGoogle Chrome用のオープンソース・ソフトウェア（Apache Licnese 2.0）です。 最近は継続的インテグレーションを実現するサーバ、サービスが人気です。コードをプッシュしたりデプロイするタイミングで自動で処理を行ってくれるのは便利ですが、その結果をリアルタイムに知りたいと思うでしょう。そこで使ってみたいのがBuildReactorです。 インストールします。Chrome Web Storeでインストールできます。 権限の確認です。あまり多くありません。 まずサービスを追加します。TravisやJenkinsをはじめ、外部のサービスも多数登録されています。 今回は例としてTravisを使ってみます。 ユーザ名を入れると登録されているプロジェクトが出てきます。 Jenkinsの場合はURLを含めて設定を行う必要があります。 後は待っているとデスク
【書評】手動デプロイからの卒業指南書「継続的デリバリー」
継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化著者／訳者：David Farley、Jez Humble、和智 右桂、高木 正弘出版社：KADOKAWA/アスキー・メディアワークス発売日：2012-03-14大型本：544ページISBN-13：9784048707879ASIN：4048707876 レビューに参加させていただいた縁でアスキー・メディアワークス社様より献本いただきました。和智さん、高木さんの黄金コンビによる翻訳です。 デプロイ自動化に関する話を網羅的に扱った本はこれがはじめてでしょう。 上級技術者向けと書かれているように内容は結構ハイレベルで、構成管理、CI、テスト戦略についての前提知識が求められるように思いますが、アジャイルなプロジェクトの中で日々改善を繰り返している人たちにとっては理解しやすいのではないかと思います。 デプ
継続的デリバリのパターン
継続的デリバリを導入しようとする前に、いくつかの準備が必要です。真っ先に必要なのは、ビルドサーバに合うソースコード管理システムです。ビルドサーバは継続的統合を実施するサーバにもなります。ひとつひとつのチェックインをビルドできるサーバでなければなりません。一般的に言って、この用途では“既成”のビルドサーバが欲しくなります。チェックインを監視して、自動でビルドをする仕組みを構築するのは、想像以上に大変です。利用しているソースコード管理システムにフックできるトリガがあるとしても、ビルド失敗時の通知機能のような他の機能を実装するには割に合いません。 リソースが限られているとしても、継続的デリバリにとってステージングサーバは重要です。ステージングサーバは本運用環境に可能な限り似せておく必要があります。ここで第一の問題は“予算がいくらあるか”ということです。本運用環境のデータベースサーバがとても高価な
最初から完璧な開発環境を作ろうとする時の罠 - プログラマの思索
良い記事があったのでメモ。 自らも肝に銘じておく。 未知の領域で開発を始める時には、環境を整えすぎてはいけない - 愛と勇気と缶ビール (引用開始) 未知の領域って何ぞいな、というとだいたい以下の二つ。 ・開発経験のないプラットフォーム。場合によっては触ったことのない言語を含む。(e.g. iOS, Android) ・今まで触ったことのない言語を用いた開発。 世の中にはエディタ・IDEからCIまで沢山の開発を支援するためのツール・枠組みがあるが、新しい領域に挑戦する時にはこれらの開発環境をあまり整えすぎない方がいい気がしている。 というのは、最初から「エディタも完璧に設定して、テストも全部書いて、JenkinsでCIするようにして、デプロイの前にビルドが走るようにして…」というようなセットアップを全部やろうとしてしまうと、それ自体に時間がかかって、それだけである程度満足してしまうから。単
継続インテグレーションは強みではなくなった: 柴田 芳樹 (Yoshiki Shibata)
Subversion/Gitなどを使用したソースコード管理、Jenkinsを使用した継続的インテグレーション、様々なxUnitフレームワークを使用した自動テストなどをソフトウェア開発組織として実践することは、今日では、その開発組織の技術的な強みではありません。 それらを実践しないことが、ソフトウェア開発組織の「弱み」なのです。また、組織としてそれらの実践を推進しない、あるいはサポートできないマネージャも「弱み」となります。さらに、大規模なソフトウェア開発組織においては、それらのためのインフラ整備をプロジェクトごとに立ち上げなければならず、サポート部門が存在しないことも弱みとなります。※1 ※1 プロジェクトを始めるごとに、ソースコード管理やJenkins用のサーバの調達、OSから様々なツールのインストールを一通り行うためには、それなりの時間を要します。したがって、バックアップをも含めて環境
Testing Rails apps with Jenkins - komagataのブログ
JenkinsでRailsアプリをテストする。 環境 さくらのVPS 512Debian 6.0.1 squeeze Jenkinsのインストール さくらのVPSにDebian squeezeをインストールする方法はこちら。 $ wget -q -O - http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key | sudo apt-key add - $ sudo vi /etc/apt/sources.list deb http://pkg.jenkins-ci.org/debian binary $ sudo apt-get update $ sudo apt-get install jenkins jenkinsユーザーが作成されて8080にjenkinsが立ち上がる。 nginxでのReverse proxyの設定 example.c
Buildbot
Buildbot is dropping support for Python 2.7 for the master. Users are encouraged to migrate to Python 3 as soon as possible.More info Buildbot BasicsBuildbot is an open-source framework for automating software build, test, and release processes. Learn more Automated Build, Test, and ReleaseBuildbot can automate all aspects of the software development cycle: Continuous Integration, Continuous Deplo
「継続的インテグレーション」について - cactusman日誌
id:Ewigkeitのブログで、CIについてはここのブログ読んでね、と言及されたんですが、対象記事はCIについてあまり書かれておらず、しかも、古い記事を調べてみてもいい内容がなかったので、ここで改めて「継続的インテグレーション」について説明します。 「継続的インテグレーション（以降、CI*1）」とはXPのベストプラクティスの一つです。 原典として、マーチン・ファウラーの論文があります。 ここでは頻繁にインテグレーション作業を行うと、少し難しく表現されていますが、ものすごく簡単に言いますと、デイリービルドやナイトリービルドのように1日に1回ビルドするのではなく、1日に何回もビルド*2を行う、ということです。 また、プロジェクトの後期に行われるモジュールの結合やシステムテストといったことも1日に何回も行います。 具体的な例として、 チェックアウト コンパイル Unitテスト パッケージング
1000Speakers@Sendai #1で話してきた - marsのメモ
誰かが言った「ブログを書くまでがセンスピだ」と。 1000speakers-sendaiView SlideShare presentation or Upload your own. (tags: 1000speakers)＃5枚目のスライドを人前で言えただけで，もう満足です。 ＃ホントウにありがとうございます。 10分枠に話をまとめるのはちょっと手強くて，マジメにCIのこと話してたら尺が足りなそうなのでネタに走りました。それでも言いたい事は大体言えたので良しとするか。 若干フォローを。 PHPでのHudsonの活用については，id:ssogabeさんがいろいろ書いてます。→[PHP] - ssogabeの日記 Hudsonの日本語のページはこちら。→Hudson - 日本語 最近，id:onozatyさんがSelenium AESのHudsonプラグインを公開してくれました。 id:c
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
継続的デリバリがイノベーションを加速する
Hudson - 日本語 - Hudson Wiki