Amazonのチームはどのように継続的デリバリーを行っているかSpring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
GitLab CIでRailsアプリをお手軽CI開発する - Tech Inside Drecom
Variables ビルドに必要なんだけどリポジトリに直接コミットしたくないような変数をいれておくことができます。（例：Slackのトークンやsshの秘密鍵など） ここに設定しておけばジョブ実行時に環境変数として使うことができます 3. gitlab-ci.yml をリポジトリにコミットする http://doc.gitlab.com/ce/ci/yaml/README.html や http://doc.gitlab.com/ce/ci/quick_start/README.html を参考にファイルを作ってください Railsアプリをテスト、静的解析、自動デプロイをするための設定サンプル こちらになります https://github.com/sue445/gitlab-ci-example 普通にRailsアプリをビルドするだけなら上記ファイルをコピペするだけでほぼいけると思います。
ビルドやテスト環境の自動化は、顧客の一声でつぶされてしまった～自動化の現場の真実（前編）。システムテスト自動化カンファレンス 2015
ビルドやテスト環境の自動化は、顧客の一声でつぶされてしまった～自動化の現場の真実（前編）。システムテスト自動化カンファレンス 2015 テスト自動化研究が主催するイベント「システムテスト自動化カンファレンス 2015」が、2015年12月13日に、六本木のヤフー株式会社で開催されました。 午前中に行われたセッション「自動家は見た～自動化の現場の真実～」には関西のコミュニティ「おいしが」のメンバーが登壇。テストを含む開発環境を自動化しようとしてきたエンジニアの、現場での苦悩と苦労をリアルに紹介しています。 その内容を前編、中編、後編の3本の記事にまとめました。この記事は前編です。 自動家（オートメータ）は見た！ 自動化の現場の真実。 「おいしが」の前川博志氏。 おいしがから来ました。グループ名にあんまり深い意味はありません。 自動化で発表される事例は、わりと恵まれた環境で、すごい能力を持って
CI で PHPコードスタイルをチェックする Style CI - Shin x Blog
PHP コードスタイルのチェック、整形を行うサービスである Style CI を紹介します。 このエントリは、Laravelリファレンス Advent Calendar 2015 の22日目です。 Laravel 公式が利用しているサービス Style CI は、Alt Three が運営している GitHub にホストしている PHP コードのコードスタイルをチェックするサービスです。 GitHub へコードを push すると、コードチェックが行われ、適合しないコードがあればエラーになります。メールによるエラー通知も飛んできます。 Style CI のサイトに行くと修正が必要が箇所のコードが提示されます。 shin1x1/phpkansai-20151216-demo - StyleCI チェックできるフォーマットは、インデントやブレース位置、文字エンコーディングなどの基本的なものから
Travis CIでビルドごとにiTunes ConnectのValidationを自動的に実行する - 24/7 twenty-four seven
コマンドラインからiOSアプリケーションをiTunes Connectにアップロードする - 24/7 twenty-four seven ↑ こちらの記事で書いたように、コマンドラインからiTunes Connectへのアップロードや、バリデーションができるのを利用して、Travis CIを使ってビルドするたびに自動的にバリデーションを実行するようにしました。 これにより、プライベートAPIを利用していたり、必須なサイズのアイコンやLaunchImageが無いなどの理由でバリデーションエラーになってアップロードが失敗するということが未然に防げます。 ARCを使う場合、ヘッダに載っていないメソッドを呼ぶのはコンパイルエラーになるので、知らずにプライベートAPIを使ってしまうようなことは現在はほぼありません。 しかし、iTunes Connectのバリデーションはあまり賢くないので（おそらく
Travis CI (Pro) の実行をジョブの並列化とBundlerとCocoaPodsのキャッシュで速くした - 24/7 twenty-four seven
ユビレジではTravis CIを使って、テストの実行とベータ版のTestFlightへのアップロードを自動化しています。 Pull Requestが送られた時と、マージされた時に自動でマージした結果のベータ版が配布されるので、手元で変更をすぐに試すことができて便利です。 【参考】 Travis CIでiOSアプリのテスト＆ベータ版の配信に使っているRakefileを改善したメモ - 24/7 twenty-four seven ユビレジのiPadアプリのCI環境をJenkinsからTravis CIに移行したときのまとめ - 24/7 twenty-four seven ただ、これは導入当初からあった問題なのですが、Travis CIにジョブが登録されてから終了するまで、だいたい20〜25分くらいと、少し時間がかかるのが気になっていました。 そこでジョブの並列化と、BundlerとCoco
■ - hitode909の日記
今日テストなくてめちゃくちゃに壊れてるアプリケーションのテストを一から書いてて、わりと書けてよかった。午前中セットアップに手間取ってて、午後からテスト書き始めて、小さいアプリケーションだったのでC0 90%くらいまでいけた。3年間くらいテストないせいでびくびくみんな触っててめちゃくちゃに壊れててよくなかった。テストえいって書けば書けるんだから、隙を見て書いていきたい。ずっとテストのあるWebアプリケーション眺めてるのでだんだんコツが分かって気がする。まず最初にCIに載せて、カバレッジ測れるようにする。面倒だけど、これやっておくと後で役立つ。普通にテスト書くと、実行環境までは定められないけど、CIがあれば、そこをベースに議論できる。最初は、アプリケーションのルートのモジュールをuse_okするだけ、くらいでまず通して、カバレッジも取れるようにする。たとえば、MyAppっていうアプリケーション
GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー
少し前までアプリケーションのデプロイと言えば capistrano などをコマンドラインから叩いてデプロイ、みたいなことをやっていたが、最近は少し様子が違うのでそのやり方、KAIZEN platform Inc. での事例を紹介する。 GitHub のイベントを契機に CI as a Service にデプロイを担当させる GitHub で Pull Request を送って開発するのが前提になっているのは以前にも紹介した。 最近は Travis CI や CircleCI などに代表される CI (Continuous Integration) as a Service があって、CI も自分たちで環境を構築しなくてもクラウドに任せることができる。KAIZEN では CircleCI を積極的に使っている。 これらの CI as a Service は基本的に GitHub と連携するこ
#JSオジサン でハイブリッド時代のCIツールの発表してきた - from scratch
いやー、めっちゃ楽しかったわ、JSオジサン。 もう色々と感想ブログは出てるけど、僕も一言で感想を言うと以下の様な感じです。 #JSオジサン 楽しかった。ギャルにも会えたし、typescriptオジサンにも会えた。ECMA-262 Edition 5.1を読む本も貰えたし、じゃんけんに勝ってエコバックも貰えた。50-60位の中規模なカンファレンスだとやっぱり話が濃くなるから良かった。— Yosuke FURUKAWA (@yosuke_furukawa) March 27, 2014 実際名前は知ってても顔を見たことない人もちゃんと話したことない人も多くて、そういう人たちと知り合えたのがやっぱり大きかった。 僕が発表した内容 ここ最近、substack wayでモジュールを書くことを実践してます。 本当は上のリンクにあるsubstack wayの話をすごくしたかったんですが、5分で伝えきれる
第2章 開発環境の改善～技術的負債の返済と、レガシーコードの仕様化テスト | gihyo.jp
技術的負債と開発環境の改善 本章では、サービスの成長とともに大きくなる「技術的負債」に着目し、筆者が勤務するpaperboy&co.（以下、ペパボ）で取り組んでいる開発環境の技術的負債を返済していく具体的な方法について紹介します。 技術的負債とは 技術的負債は、英語でTechnical Deptと呼ばれます。技術的負債の「概念」が最初に登場したのはWikiの開発者として知られるWard Cunninghamが1992年に発表した「The WyCash Portfolio Management System」という報文の中です。そこから年を経ること17年後の2009年に、アジャイルソフトウェア開発宣言などで知られるMartin Fowlerによって「技術的負債」という名前が付けられました。 Webサービス開発での技術的負債の例 技術的負債は、サービスを構成するソースコードそのものであるアプリ
JenkinsとSeleniumでJavaScriptのテスト自動化、最初の一歩。第1回 日本Seleniumユーザーコミュニティ勉強会
JenkinsとSeleniumでJavaScriptのテスト自動化、最初の一歩。第1回 日本Seleniumユーザーコミュニティ勉強会 1月18日に都内で開催された「第1回 日本Seleniumユーザーコミュニティ勉強会」。Seleniumプロジェクトの共同設立者であるJason Huggins氏による基調講演に続いて、有志によるライトニングトークが行われました。 本記事ではその中から、玉川紘子氏による「Jenkins x Selenium 最初の一歩」の内容を紹介します（追記：本記事のタイトルは「JenkinsとSeleniumでJavaScriptのテスト自動化」とありますが、実際の内容は「Selenium RCがJavaScriptの技術を用いて自動テストを行っている」という点がポイントという指摘がありましたので、ここに追記します）。 Jenkins x Selenium 最初の一
はてなやクックパッドの開発現場で、CIやテストはどう行われているのか？（後編）。CROSS 2014
Web技術について横断的に語り合うイベント「CROSS 2014」が1月17日都内で開催されました。「現場に聞く！テスト/CI/DevOps、実際のところどうなの」というセッションでは、フリーランスエンジニアの伊藤直也氏がセッションオーナーとして司会を担当し、クックパッドで開発まわりのエンジニアをしている舘野祐一氏、はてなでアプリケーションエンジニアをしている伏井洋平氏、KAIZEN platform Inc.の石橋利真氏らがスピーカーとして登壇しています。 セッションの前半では、テストの重要性やテストをどのくらい書くべきなのか、といった議論が行われましたが、後半ではどうすれば組織としてCIやテストに取り組めるのか。そして組織内での情報共有などについての意見が交わされました。 （本記事は「はてなやクックパッドの開発現場で、CIやテストはどう行われているのか？（前編）。CROSS 2014」
はてなやクックパッドの開発現場で、CIやテストはどう行われているのか？（前編）。CROSS 2014 － Publickey
Web技術について横断的に語り合うイベント「CROSS 2014」が1月17日、都内で行われました。 そのセッションの1つ「現場に聞く！テスト/CI/DevOps、実際のところどうなの」では、フリーランスエンジニアの伊藤直也氏がセッションオーナーとして司会を担当し、クックパッドで開発まわりのエンジニアをしている舘野祐一氏、はてなでアプリケーションエンジニアをしている伏井洋平氏、KAIZEN platform Inc.の石橋利真氏らがスピーカーとして登壇。 先進的な現場でテストやCIがどのように行われ、エンジニアのチームがどのように情報共有をしているか、本音で語るという注目すべき内容でした。本記事ではそのダイジェストを紹介しましょう。 現場に聞く！テスト/CI/DevOps、実際のところどうなの 伊藤 今日のテーマとしてはCI（Continuous Integration、継続的インテグレー
.travis.ymlめぐり
Travis CI というGithubと連動してGithubにコミットすると勝手にテストが走ってテスト結果を通知してくれる、ようするにJenkins as a Serviceみたいなやつがあって、とても便利なので知らなかった人はこの際使いましょう。 そんでTravisの設定ファイルが.travis.ymlで、プロジェクトのディレクトリに置いておくだけでいいんだけど、ごく最近rubyの.travis.ymlを書き直したので、そのときに調べたものを開陳しておこうというエントリ。 https://github.com/ruby/ruby/blob/trunk/.travis.yml これが最終的に今のRubyの.travis.ymlで、俺の趣味によるやりすぎ気味のコメントと、language: cの例としてはもっとも網羅的な(つまり微に入り際に穿った)記述が特徴。Cのプロジェクトはまずこれをコピ
GoogleのCIとテスト自動化の取り組み [GTAC 2013] - ワザノバ | wazanova.jp
[Video] http://www.youtube.com/watch?v=nyOHJ4GR4iU [Slide] http://goo.gl/76Ggf Google Test Automation Conference 2013のキーノートスピーチで、GoogleのAri Shamashが同社のCIツール & 自動化されたテストプロセスを紹介しています。 [最初の前置きが13分。GoogleのCIの紹介の内容ではないので割愛。お話としては面白いのでVideo見てみてください。] エンジニア1,5000+人が5,000プロジェクトにアサインされている １億行のコード。50%が毎月更新。 1日当たり5,500+件がサブミッションされ、１億件以上のテストケースが実行されている。 Googleのクラウドテストシステムは多機能。ビルド作成、特定のターゲットをテストでき、テストカバレッジ計算、依
CI で稀に失敗してしまうテストへの対処方法 - クックパッド開発者ブログ
技術部の福森です。 クックパッドでは RSpec と Jenkins を利用して CI による自動テストを行なっています。 テストの数は 12000 examples を越えていて、テストによっては稀に失敗する物が出てきています: 時間帯依存で失敗してしまうもの 他に同時に実行されるテストに依存しているもの (並列実行で組合せが変わり再現する) インテグレーションテストでの ajax リクエストの微妙なタイムアウト etc また、本番環境を壊さないよう、 CI で成功したリビジョンのみデプロイ可能となっており、開発者が push しデプロイしたいと思っている時に無関係な原因で失敗する事を避けたいという欲求があります。 なぜなら、再度ビルドを実行する時間 (およそ 10 分) の間待たされる事になるからです。 そこで、そのようなテスト起因での失敗を減らし、かつ開発者にそれらを修正してもらうた
GithubにあるリポジトリをTravis CI連携する手順 #junitbook - くりにっき
『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
RubyMotion のテスト、継続的インテグレーション - naoyaのはてなダイアリー
昨日は RubyMotion のもくもく会でした。 先日の RubyMotion Kaigi 2013 で 実践RubyMotion という題目で発表したのだけど、テストについてはprintデバッグ上等だ、このクソムシがとか言ってかなり適当に済ませてしまった。ので、もくもく会ではテスト周りに手をつけるぞと思い、そういえば Travis CI が RubyMotion に対応してたのも思い出し RubyMotion のテストを Travis CI で回すのを検証した。 が、手間取るかと思った Travis CI 周りはとっても簡単で、.travis.yml に language: objective-c と書くだけであっさり動いてしまった。 というわけで RubyMotion アプリの継続的インテグレーションは .travis.yml を一行書けば完了です。終わり･･･じゃあまったくブログ記
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TechCrunch
Continuous Integration and Delivery - CircleCI
