builderscon 2018 9/8 15:30 多目的教室1でのセッション
1日約70万ビルド: DockerとNomadが支えるCI/CDプラットフォーム
builderscon 2018 9/8 15:30 多目的教室1でのセッション
CIとTest Sizesの話 - asterisc
はじめに 前回 akito0107.hatenablog.com どちらかというとこっちが本編。 前回の記事ではTest Sizesについて紹介したが、今回の記事はその分類が実際の開発にどう役に立っているのかをまとめたいと思う。もちろん用語の統一も大きな意味を持つが、それ以外のことを書いていきたい。 具体的には、CIでテストのパイプラインを組む時にこの分類どおりに組んでいくと綺麗に整理でき、CI全体のスループット向上にも効果がでているという話だ。今回の話は僕たちのチームに特化した内容になるが、1) Test SizesごとにTestの起動コマンドを分ける、 2) Smallから順に実行していき、落ちるべきテストはできるだけ早期に落とす、というポイントはどこにでも使えるものだと思う。 コンテナ技術とテスト 僕たちはローカルの開発環境だけではなく、本番環境やCI環境でコンテナ技術（主にDock
インフラCI実践ガイド Ansible/GitLabを使ったインフラ改善サイクルの実現 | 翔泳社
クラウド時代に適合した 新インフラ管理のベストプラクティス！ 構成自動化ツールや仮想化／クラウドなどの技術が普及し、Infrastructure as Code（コードとしてのインフラ）が現実になりつつあります。インフラの定義をコード化できるようになると、今度はそれらを適切に管理し、最新状態を保持し、確実に本番システムに適用できる手法が求められるようになります。 本書では、こうしたインフラの管理のためにCI（Continuous Integration：継続的インテグレーション）の技術を適応させる方法を紹介します。これにより、システムの変更を継続的に維持できる管理サイクルの実現を目指します。 【本書の特長】 ・新しいタイプのシステムインフラと、旧来のインフラ管理の問題点 ・インフラ管理にCI手法を応用するメリットと適用のためのポイント ・実際のシステムを前提としたベストプラクティスをサンプ
オンラインドキュメントへCI/CDを適用している話
SkyWayとWebRTC開発者コミュニティ4年間の軌跡とCMC_Meetupで学んだこと、実践したこと
今日からはじめるCI/CD ─ CircleCI + Deployerでテストとデプロイを自動化しよう！【休日個人開発】｜ハイクラス転職・求人情報サイト AMBI（アンビ）
今日からはじめるCI/CD ─ CircleCI + Deployerでテストとデプロイを自動化しよう！【休日個人開発】 プライベートでも何か作りたい！ そんなときの「今日からはじめる休日個人開発」シリーズ、今回はテストやデプロイをGitHubと連携し、自動化させてCI/CDに対応します。 皆さん、プライベートで何か開発していますか？ 「何か作りたい」という気持ちはあるものの、いまひとつ何から始めたらいいのか分からず、動けないままの人も多いと思います。 そんな皆さんのために、「仕事以外にも休日に個人で気軽に何かを作ってみよう！」という企画の第3回です。第1回で用意した開発環境と、第2回で作成した画像を加工するツールを用いて、テストとデプロイの自動化を行います。 これまでの休日個人開発シリーズでは、Webアプリケーションを動作させる本番環境にログインし、動作しているファイルを直接修正して開発
Heroku CIが正式にリリース：簡単に、すぐに使い始められるCI
本ブログは、米国で発表した Heroku CI Is Now Generally Available: Fast, Low Setup CI That’s Easy to Use の翻訳版です。 セールスフォース・ドットコムではHeroku CIを正式リリースし、提供を開始します。これはユニットテストとブラウザテスト向けのすぐに利用可能なテスト実行環境であり、Heroku Pipelinesと密接に統合されています。 最近の傾向として、多くの開発者がソフトウェアの品質を担保しながら素早く機能を最適にリリースするために、継続的インテグレーション（以下、CI）をベストプラクティスとしています。またそれは継続的デリバリー（以下、CD）を実現するために必須となっています。ビルド、デプロイメント、そしてCDの実現のために、Heroku CIは利便性、開発体験、そしてCIの機能を飛躍的に向上します。開
DockerについてLTした内容と細かい話 - light_and_cat
speakerdeck.com ホスティング事業部内のホスtechMTG#3にてDockerについてLTしました 資料に入り切らなかった小ネタなどをここでは紹介。 LT資料の言い回しついての補足 specコンテナ: コンテナ内でRSpecを実行してコードをテストするためのコンテナ dbコンテナ: RSpec実行コンテナと接続しているMySQLが起動されたコンテナ 参考資料 最近だとこの辺がDockerについて特集記事がありました Software Design 2017年2月号 WEB+DB PRESS Vol.98 実際に使ったコマンド 資料では若干オプションなど省いてたので完全版 specコンテナ側の起動時 $ docker run -dit -v $(pwd)/spec/features:/tmp/muu/spec/features --link db spec bash E2Eテス
Jenkins入門【2.0対応】 － オープンソース継続的インテグレーション（CI）ツール
Jenkinsをインストールして使ってみよう［Mac／Linux／Windows］ 継続的インテグレーションツール「Jenkins」の使い方を基礎から解説する連載がスタート。初回は、Jenkinsの概要とインストール手順、簡単なジョブの登録方法を説明する。 Jenkinsでテストを実行してみよう＋Rubyテストの基礎（RSpec＆Turnip使用） Jenkinsを使って小さなテストを自動実行して、開発スピードを飛躍的に向上させよう。また、MacでのRuby／Rails環境の構築方法から、テストフレームワーク「RSpec」とインテグレーションテスト環境「Turnip」を使ったテストの書き方までを解説する。
Jenkins 2を使った究極のpipeline ~ 明日もう一度来てください、本物のpipelineをお見せしますよ ~
This document contains code for a Jenkins pipeline that defines stages for compiling, testing, packaging, deploying, and smoke testing a build. It also contains code to send notifications to Typetalk if the build fails. Additional code shows how to fetch pull request branches from a Git remote and check if a pull request is open for a given branch.Read less
CIでの確認項目 - 弥生開発者ブログ
こんにちは、Misoca開発チームのmzpです。 GWは日光に遊びにいっていました。 MisocaではJenkinsを利用してCIによる自動テストを行なっています。最初はrspecを実行するだけのシンプルなものでしたが、都度設定を追加し、様々な項目をCIで確認するようになっていきました。 今日はそのCIで確認している項目について紹介したいと思います。 確認している項目 静的解析 コーディングスタイルのぶれや脆弱なコードを書かないようにするために、各種静的解析ツール(Rubocop、HAML-Lint、Brakeman)を導入し、警告がでないことを確認しています。 導入した直後は違反箇所の一覧を作成するのみで、ジョブの成否とは無関係でした。しかし、だんだんと違反箇所の修正をしなくなってしまったので、今は違反箇所がある場合はジョブが失敗する設定にしています。 rspec 全specの実行はrs
CircleCI + Docker で Infrastructure CI (Chef + Serverspec) 環境を構築した - kakakakakku blog
近況 3月から DevOps 関連の技術的負債の解消に取り組んでいて，動かなくなった Chef を直したり，秘伝のタレ（手動）で構築されたサーバ設定を Chef にリバースエンジニアリングしたり，Serverspec を導入して稼働中のサーバの差異を確認したりしている． 他にもウェブサーバのパフォーマンスチューニングをしたり，Zabbix / Kibana / CloudWatch で可視化したり，不要なアラートを消したりもした．あと Vagrant 環境を自動構築できるようにしたり，Packer を使って Vagrant Box を改善したり，デプロイ手順を正常化したり，テストの品質向上の目的で Capybara を導入したりもした． 最近はキャッシュサーバをリプレイスしたり，AWS のネットワーク構成を変更するなど，とにかく様々な施策を試しているけど，全然まだまだという感じで，圧倒的成
まだ CircleCI で消耗してるの？ - Qiita
概要 もう随分と前に TravisCI から CircleCI へ乗り換えたのですが、いかんせん、便利な CircleCI をもってしても Android のプロジェクトのビルド時間は長くなり続け、ついに 1 回のビルドに 20 分を費やすほどにまで成長してしまいました。いくつか無駄を省いたり、キャッシュをしてみたりと言った策を講じたものの、目立った改善が得られませんでした。そこで CircleCI を脱却してみることにしました。現在、CircleCI を脱却し Wercker を利用することで 1 回のビルドが 5 分ほどで終わるようになりました。この記事には、何がどのようにして短時間で済むようになったかを書き記してあります。 問題の根源 そもそも CircleCI で時間がかかっている部分はどこかというところから見ていきます。現在のプロジェクトで使用している分には、以下に上げる部分でか
ポストJenkins時代のCI戦略
VSハッカソン倶楽部 CI勉強会で発表した資料となります。 https://vshtc.doorkeeper.jp/events/26853
Private Presentation
Private content!This content has been marked as private by the uploader.
CircleCIで回しているRspecのテストを40%高速化しました - production.log
タイトルの通り、CirclCIで回しているテストを40%高速化した話をします。 うちの会社では、342files, 27300examples強を回しており、テスト時間が肥大化傾向にありました。 そこで、テスト高速化を図ろうと試行錯誤したので、その過程を書きます。 ※RRRSpec使えよ！というツッコミはなしで。CircleCI上で試行錯誤の記録を残すために書きます。 また、spec自体の高速化ではなく、CircleCIの仕様に合わせた高速化の方法についてのみを書きます。 やり方 並列実行する 遅いテストファイルを特定する 遅いテストファイルを分割する なんと、この2つだけです！ シンプル！なんてシンプル！ 並列実行して、遅いテストを特定するだけです。 そもそも技術力なんていりません。気合と根性*1で速くできます。 並列実行する 並列数を変更 CircleCIで並列実行数を増やすオプション
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CircleCI 2.0 を使い倒そう / phpcon kansai 2018 circlci docker
Apple が buddybuild を買収
Sign in | Shippable
GitLab CI x Docker のススメ
Concourse CI