Jenkins Day Japan 2021に登壇させていただきました - MonotaRO Tech Blog
こんにちは。金谷です。 2021年12月10日に行われました、Jenkins Day Japan 2021に登壇させていただいた報告です。 cloudbees.techmatrix.jp 本ブログにご訪問いただきました テクマトリックス株式会社 の方にお声がけいただいたことがきっかけで、登壇、講演させていただくことになりました。 改めまして、貴重な機会をいただき、ありがとうございました。 登壇のために資料作りをしたのですが、 Software Design連載 の中であまり語られていないJenkinsまわりの話をまとめることができたことも良かったと思っています。 発表資料 レポート おまけ (講演で話せなかったこと) ジョブ設計の話とソフトウェア設計の関連性 発表後の質疑応答について 運用周り 今後の話とエンジニア募集について 言及している資料 発表資料 発表資料はこちらです。 モノタロウ
travis-ciが設定してあるリポジトリにpull requestする前にやるべきこと - xuwei-k's blog
自分の中では、これはわりと常識になっている感があるが、やってくれない人多いので、あらためて説明を書いてみる。 前提として、プログラミング言語関係ない話です。 あと、travis-ciにも限らない話です。が、全部ひっくるめてなんて呼べばいいかわからないので(オンラインCIサービスとか？)travis-ciのような何かを意味的には全部含めて、以下単にtravis-ciといいます。 これから書くことは 「プロジェクトのコミッター側のレビューのコストの減らすため」 の話です。プロジェクトによっては 「中途半端な状態でもどんどんpull reqしてもらっていい(丁寧に対応してくれる)」 とか、そもそもOSSじゃなく仕事だったり、pull reqの種類(議論するために中途半端な状態でわざとpull req)によっては当てはまらない場合があるかもしれません。 さて、本題に入ります。一言で言うと 「pul
OSS版 Drone.io を社内で使い始めてる話 - Qiita
標記の通りで、Docker tips直球じゃなかったりしますが、コアにDockerがいるツールではあるよと言うことで。 どんな感じで運用しているかの話をしてお茶を濁しつつDocker話題を交えていきます。 インストール Puppetのマニフェストをきっちり書いて、後述するようにそのマニフェストをdrone自身にCIさせている。 DockerのPuppetモジュールとして garethr-docker と言うのを使っている。Droneのマニフェストはインストール手順を見て自分で書いた。 インスフトール手順をレシピに落とすのはそこまで難しくなかった。Puppetが苦手なら、ChefなりAnsibleなりで一度一通り書いておくと安心感があると思う。 監視 munin で雑にやっている。せっかくDockerが入るので普通にmuninのイメージを引っ張って監視が設定できる。便利。あ、 udzura/
inforno :: 俺的モダンなPythonのOSS開発環境
趣味プログラマです、こんにちわ。一応生きてます。 さて、Pythonista各位におかれましてはmoratoriumをエンジョイされていますでしょうか。そろそろライブラリも著名なものはPython3に対応してきましたし、そろそろ本格的にPython3、となっているころ合いですね。というか、Python3に対応してないとちょっと恥ずかしくなってきましたね。 とはいえ、Python2は根強く残るでしょう。というわけでPython2とPython3両方で動くコードを書きましょう。テストも書くのは当たり前ですし、せっかくなのでCIもしましょう。 と私も最近思ったので快適に開発を進めるための環境についてメモです。 github : 言わずもがなですね。 travis : githubと連携してCIできるサービス。P言語にも対応していて、最近アツいです。 tox : 複数のPython処理系でvirt
Ciしてるかい？
The document discusses continuous integration and delivery practices for software development. It recommends committing code changes to version control daily, configuring an automated build and test process every time code is committed, and deploying successfully built code to testing or production environments. This allows developers to identify issues early, prevent broken code from being deploy
WebKit サーバーというものを作ってみた - IT戦記
みなさん お久しぶりですヽ(´ー｀)ノ夏休みの宿題終わりました？ 毎日が夏休みの最終日みたいな生活してるあまちゃんです！ さてさて 今日は WebKit サーバーというものを作ってみたので、紹介してみます。 WebKit って何？ WebKit っていうのは Chrome や Safari の中に入ってるブラウザのエンジンのことです！ 実はブラウザっていうのは、エンジン部分と見た目の部分（タブとかボタンとかね）に別れていて、意外と違うブラウザでもエンジン部分は同じものを使ってるってことも多いんですよ(*´ー｀) ブラウザのサーバーってどういうこと？ 要は、サーバーサイドでブラウザを起動して JavaScript を実行したり、 JavaScript が実行されないと読めないページから値を持ってくるのに使ったりしようという魂胆です。 今まではそういうのなかったの？ 実は、今までは JavaS
- 継続的インテグレーション
継続的インテグレーション 原題: Continuous Integration Martin Fowler Chief Scientist, ThoughtWorks Matthew Foemmel ThoughtWorks 「確実なビルドを行う」 -- これはどんなソフトウェア開発プロセスであれ重要なことだ。そのわりには、このことがきちんとされていないことに驚かされる。本論文では、Matt が ThoughtWorks 社でのある大規模プロジェクトにおいて採用したプロセスを紹介する。このプロセスは全社的な広がりを見せつつある。テスト部分も含めて「全てが自動化された」「再現可能な」ビルドを、「日に何度も」行うことに力点がおかれている。このプロセスを用いれば、開発者はインテグレーションを毎日行うことになるので、インテグレーションに伴う問題を減らすことができる。 継続的インテグレーションの恩恵
本当はすごい codefirst の開発環境 - suer のブログ
(本記事は @suer, @mallowlabs, @mzp がノリノリで共同執筆しました！) 近代的なソフトウェア開発に必要なツールは3つある。 分散バージョン管理ツール ITS CI ツール 私はこれに AsakusaSatellite (以下AS)を加えたいと思う。 以上の4ツールを使用することによって、迅速なコミュニケーション、洗練された自動化をベースとした開発リズムを体験することができる。 このあとの節では具体的なユースケースをベースに、上記ツールの連携方法及びそのメリットをみていく。 ユースケース：開発中にソースコードの特定行で例外が発生した原因を探る ここは codefirst の開発室。 @suer と @mallowlabs と @mzp はリズム良くコードを書いています。 そんなとき、ビルドの異常を知らせるポップアップが表示されます。 さっそくAS 上でミーティングがは
Jenkinsの生みの親が語る、継続的インテグレーションの未来 － ＠IT
2011/06/06 5月24日、日本Javaユーザグループ（以下、JJUG）の主催による「JJUG Cross Community Conference（以下、JJUG CCC） 2011 Spring」が行われた。JJUG CCCはJJUGが年2回開催している定例イベントであり、Javaに関する最新の動向や活用事例などが紹介される。 本稿では、オープンソースのCIサーバ「Jenkins」の生みの親である川口耕介氏による基調講演の様子をお伝えする。 「Jenkins」はソフトウェアプロジェクトのビルドやテストを自動化する継続的インテグレーション（CI：Continuous Integration）サーバの一種である。もともとは「Hudson」という名称で開発・公開されていたが、商標上の問題によってJenkinsに改名された。 JJUG CCCの基調講演は、その生みの親であり現在もプロジェ
ウノウラボ by Zynga Japan: PHPで利用出来るテストと開発に便利なツール
こんにちは。yukiです。 今日はテストや普段の開発に便利なツールのご紹介をしたいと思います。PHP限定のツールですので、ご了承下さい。 ZyngaJapanでは、昨日リニューアルオープンした「ファームビレッジ」でも、Jenkins(旧Hudson)によるCIを行って開発しており、TDDやJenkinsでのCIを利用する文化がだんだんと浸透してきています。Jenkinsのプラグインとして利用できるものも多くありますが、当然ながらコマンドラインからも利用出来ますので、コミット前に自分のコードをチェックすることもできます。 phpcpd コードの中でコピー&ペーストで記述されている部分を検出してくれます。 どの程度の重複から検出するかを柔軟に設定できるので、まず大きな部分から修正するなど判断ができ便利です。 $ phpcpd /path/to/project phpcpd @package_v
Rhonabwy » Setting up a python CI server with Hudson
I start with a basic virtual machine – in this case, I’m using Ubuntu Server 9.10. Once you have a basic machine installed, I recommend you make sure everything’s up to date with patches. sudo apt-get update sudo apt-get dist-upgrade If you haven’t already, consider installing an ssh server for remote login. You don’t need it for hudson, but I find it makes administration easier. sudo apt-get in
JenkinsとPythonの連携 - kuma8の雑記帳
はじめに 今回は、Jenkins と Python の連携についてです。 使用するツールは、とても便利なテストフレームワーク nose と カバレッジ coverage との連携についてです。 nose連携 まず、 nose との連携からです。 nose をそのまま実行したのでは、Jenkinsに取り込めないため、XUnit形式のレポートを出力する必要があります。 XUnit形式のレポート出力には、 unittest-xml-reporting を導入する必要があります。 unittest-xml-reporting がインストールされていると、noseの出力レポートをXUnit形式にすることができます。 インストール $ easy_install -ZU nose $ easy_install -ZU unittest-xml-reportingnose の使い方は割愛しますが、コマンド
Capistranoのビルドを管理する·Webistrano MOONGIFT
Ruby on Railsはマルチプラットフォームで動作することもあり、ローカルで開発を行いリモートサーバで動かすというのが当たり前に行われている。その際、ローカルサーバで開発、アップロードを行ってリモートサーバへログインしてリブート…等とやるのはスマートではない。 CapistranoをWebベースで管理する サーバ一台ならば良いが、複数のサーバに対して更新ファイルを配信してリブートするなんてのは現実的ではない。そこで使われるのがCapistranoだが、さらに便利にしてくれるのがこれだ。 今回紹介するオープンソース・ソフトウェアはWebistrano、WebベースのCapistrano管理ツールだ。 Webistranoはプロジェクトを作り、ホストやレシピを設定してCapistranoの運用を簡易的にしてくれる。ターミナルから使うのが基本だが、複数人で開発を行っている場合は更新、リブー
単体テストを“神速”化するQuick JUnitとMockito
単体テストを“神速”化するQuick JUnitとMockito：ユカイ、ツーカイ、カイハツ環境！（16） Quick JUnitプラグインの3つの大きな特徴 近年、JUnitとHudsonを利用した継続的インテグレーション（CI）によるテストの自動化や、テスト駆動開発（TDD）の普及などにより、ユニットテスト（単体テスト）のテストコードの作成が重要視されています。 今回紹介する「Quick JUnit」プラグインは、JUnitによるテストコードの作成と実装を支援するEclipseプラグインです。Quick JUnitプラグインは石井勝さんにより開発されていましたが、石井さんが不慮の事故により死去後、Quick JUnitプラグインプロジェクトにより開発が継続されています。優れたオープンソースプロジェクトの模範のようなプロジェクトです。 訂正のお知らせ 故人のお名前について間違いがあり、修
Buildbot で継続的インテグレーション - mixi engineer blog
こんにちは。パートナーサービス部の加藤和良です。 前回、mixi における開発者テスト について説明しました。だいぶ間があいてしまいましたが、今回は、そのテストを定期的に実行する 継続的インテグレーション の仕組みを紹介したいと思います。 テストが遅い 実は、mixi のテストは「遅い」という大きな問題を抱えています。 Micheal Feathers は『レガシーコード改善ガイド』のなかで、単体テストが高速に実行できることの重要性を解き「単体テスト」を厳しく定義します。 次に当てはまるものは単体テストではない。 データベースとやり取りする ネットワークを介した通信をする ファイルシステムにアクセスする 実行するために特別な環境設定を必要とする (環境設定ファイルの編集など) 上記に該当するテストが悪いというわけではない。多くの場合において、そのようなテストを書く価値はあり、しばしばテスト
Hudsonを３ヶ月ほど使ってみての所感 - wyukawa's diary
Hudsonを現場に実際に導入して３ヶ月ほど経った。 周りの反応も聞きながら運用していったがその過程で感じたことを書いておく。 まず結論から言うと導入して正解だった。というか導入していなかったらやばかったと思う。 これは導入した張本人だから多少の贔屓目があるのは事実だがそれを除いても効果は大きかった。 周りの反応もいい。導入がすんなりいった要因にはHudsonはTracやRedmineと違っていままでの作業のやり方を変える必要が無いのも大きい思う。ビルドスクリプトとCIわかっている人間が一人いればとりあえずまわる。ダッシュボードがあるから共通のコミュニケーションパスになる。管理者受けもいい。 導入の最初の目的はコンパイルエラーの撲滅だったが効果を発揮したと思う。 ただ導入するだけではダメでやり方もちょっとづつ変えた。 例えばメール通知は最初はリーダだけだったが、実際にコーディングするのは担
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://access.redhat.com/containers/
f-zipper-with-pipe-forward
JUnit XML output for QUnit tests compatible with PhantomJS 1.3