Travis CI が便利
クラウド Jenkins 氏な感じの Travis CI がとても便利。 what is Travis CI GitHub のリポジトリをビルドして結果を通知してくれるWebサービス。Perl プロジェクト対応。 使ってみる Baya で試してみます。 リポジトリのルートに .travis.yml というファイルを用意します language: perl perl: - "5.14" - "5.12" - "5.10" notifications: irc: channels: - "irc.freenode.net#baya" on_success: change on_failure: always ビルドする perl 環境の設定と、通知をどこにどのタイミングでするかを書いてあります。このあたりに詳しく 載ってます。 GitHub で travis-ci との連携を ON にします
%25E3%2581%25AB%25E3%2581%25A4%25E3%2581%2584%25E3%2581%25A6%25E3%2581%258A%25E8%25A9%25B1%25E3%2581%2597%25E3%2581%2597%25E3%2581%25BE%25E3%2581%2597%25E3%2581%259F)
DevLOVEでJenkins(というかCIとインフラ)についてお話ししました - けんちゃんくんさんのWeb日記
同僚の@papandaからの依頼とあれば断わる理由はないので、DevLOVE HangarFlight - Snow Barrage -で、Jenkinsを中心としたCIとそのインフラについてお話ししてきました。 Jenkins勉強会で発表した内容に、それから半年の動きを足した内容となっています。 主たるコミュニケーションツールであるIRCを中心として開発者が開発に集中できること 有限のサーバリソースをどう使って快適なCI環境を手にいれるか ということが、ここ1年くらいホットなトピックだったので、そのために私たちがやっている取り組みをお話させていただきました。 何人かの方から、JenkinsとIRCと会話するのは面白い、GanetiやTravisは知らなかったけど興味が湧いたという声を頂いて、発表してよかったなぁと思いました。 また、懇親会では、Vundleの記事やWeb+DBの特集がよか
Tips for Keeping Jacascript Libraries from Colliding
Namespacing Javascript libraries can often be used in ways the authors did not foresee. Global variables present many opportunities for conflict among Javascript libraries. Authors should use namespacing techniques and JSLint to avoid polluting the global namespace and thus avoid collisions with other libraries. The problem People who run Zendesk help desks like to integrate with other services. W
Continuous Deployment of iOS Apps with Jenkins and TestFlight - Shine Solutions Group
Continuous Deployment of iOS Apps with Jenkins and TestFlight I thought it was about time I should put together a simple guide on using Jenkins to build your iOS application – and for those of us that use the awesome testflightapp.com website for managing our iOS app distribution for testing, I have included details on creating a Jenkins job to publish the latest successful artifact to testflighta
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
仮想環境で本番環境と同等の環境を作るHudson と Vagrant - maeshimaの日記
Dr Nic's Making CI easier to do than not to with Hudson CI and Vagrantを見てのメモ。開発環境と本番環境の環境が違って、開発環境だとうまくいくけど本番環境だとエラーみたいなことがよくある→仮想環境 & 自動化で解決!みたいな話。 紹介されてたツール vagrantとHudsonについて紹介されていた。あとpuppetも軽く。 Vagrant Vagrant は VitrualBox用の仮想環境を作るのを自動化するツール。あとVMと実環境のディレクトリをリンクしたり。 Hudson Hudsonは有名なCI(continuous integration)用のツール。とは言えCIってあんまり知らない。調べたところ CIは，Extreme Programmingに端を発し，Martin Fowlerによって広められた概念で，狭義
Continuous Integrationの12の勘所 - Fly me to the Luna
個人的にCIは大好きで、いろんなところで首をつっこんでは、仕組みを学んで来ました。その勘所をかりかり書いてみました。内容が固いので文体も固いですが、この記事書いている人はこんなに固くないです。むしろゆるゆるです。 最初で全ての環境(ビルド・テスト・CIサーバーの設定)を整えられればパーフェクトだけれども、一度に全部やりきるのはきっと現実的ではない。開発環境としてフルスタック揃ったものはいくつもでているけれども、プロジェクトごとに違う設定は必ずどこかにあるからだ。例えば開発用のDBは各マシンに用意しているけれども、インテグレーション用のDBは別途用意している、とか。設定は「こうすれば良くなるかも」という継続的な改善をしていくつもりで、一番最初は軽めに1時間くらいでできる範囲で一本通す。 小さく産んで、環境を壊さない程度の改善を少しずつ加えて育てていく。育てられるのは製品コードやテストコードだ
Bitten
Bitten - A continuous integration plugin for Trac Bitten is a Python-based framework for collecting various software metrics via continuous integration. It builds on Trac to provide an integrated web-based user interface. See Bitten in action: Build Status Documentation User Guide White Paper Frequently Asked Questions Download Download Bitten Support & Development Mailing List IRC channel Devel
特集：Hudsonを使ったアジャイルな開発入門｜gihyo.jp … 技術評論社
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
第1回 Hudsonの導入 | gihyo.jp
継続的インテグレーションとは Hudsonの具体的な紹介に入る前に、まず簡単に「継続的インテグレーション」（Continuous Integration、以下CI）のおさらいをしましょう。CIは、Extreme Programmingに端を発し、Martin Fowlerによって広められた概念で、狭義には、別々に開発された部品を持ち寄ってお互いの動作を検証する「統合テスト」を早い段階から恒常的に行うことを指します。この当初の概念には必ずしも統合テストの自動化という考え方は含まれていませんでしたが、最近では、CIは単に統合テストだけではなく、広くビルド及びテスト全般を恒常的に行うことを指すようになり、またこれを現実的な工数で実現するための必須の手段として、ビルド・テストの工程を極力自動化する、という事が重要なポイントの一つになってきました。 この考え方の背景の一つには、コンピュータの高性能
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Something went wrong.