WEB+DB PRESS plus CircleCI実践入門 ──CI/CDがもたらす開発速度と品質の両立 著者 浦井誠人,大竹智也,金洋国 著 発売日 2020年9月14日 更新日 2020年9月14日
![CircleCI実践入門 ──CI/CDがもたらす開発速度と品質の両立 | Gihyo Digital Publishing … 技術評論社の電子書籍](https://cdn-ak-scissors.b.st-hatena.com/image/square/596daa699fecb42d9693635c71caffe25d8ea1d3/height=288;version=1;width=512/https%3A%2F%2Fimage.gihyo.co.jp%2Fassets%2Fimages%2Fogp%2F2020%2F978-4-297-11412-1.jpg)
開発者はGitLabのプロジェクトにおいてmasterブランチにpushすることが可能な権限(Owner以上)を有していること 開発者はプロジェクトのリモートリポジトリとssh接続できること 開発者のマシン環境にGradleとOpen JDKが予めインストールされていること 「GitLab CI」を理解する 「GitLab CI」とは GitLab CIはCI(Continuous Integration、継続的インテグレーション)ツールの一つです。GitLab 7.14から8.0へのメジャー・アップデートにより、GitLab CIはバージョン管理機能を有したGitLab CE/EEに統合されました。 From 7.14 to 8.0 | GitLab.org / GitLab Community Edition · GitLab 「GitLab Runner」とは 「GitLabサーバー
米Yahoo!、自社で利用している継続的デリバリのためのツール「Screwdriver」をオープンソースで公開。大規模インフラに対応 継続的デリバリとは、おおまかに言えばプログラマがコードを変更すると自動的にビルドされ、テストが実行され、問題がなければ本番環境へのデプロイが行われることで、つねに最新のリリースを迅速にユーザーへデリバリできるというものです。いわゆるDevOpsを実現する代表的な手法です。 これを実現するためには、ソースコード管理システムでソースコードがコミットされると自動的にビルドシステムが走り、ビルドの結果を自動テストにかけて、テスト結果によりデプロイが行われるなど、一連のツールが自動的に連係して動作するシステムが必要となります。 今回公開された「Screwdriver」は、この一連の自動化を実現するためのツールです。GitHubやBitbucketなどのソースコード管理
2016 - 10 - 12 CircleCIでyarnを使う Node npm CircleCI 世間はnpm互換のパッケージマネージャであるyarnで盛り上がっているようです。 github.com ヘーシャではCircleCIでnpmなプロジェクトをいっぱいビルドしているので早速雑に試してみた。 github.com circle.yml とりあえず circle.yml はこんな感じ machine: node: version: 4.6.0 post: - curl -o- -L https://yarnpkg.com/install.sh | bash dependencies: cache_directories: - "~/.yarn-cache" pre: - yarn --version override: - yarn install test: override:
With Travis CI, you never have to choose between speed, quality or cost: Connect directly to Assembla, GitHub and more. Parallel building with our Build Matrix. Simple syntax means faster time to value. Clean VMs for every build. Live build request. Auto-deployment on passing builds Pull request support. Test on Mac, Linux and iOS. Test on unique architecture like AMD Graviton 64, IBM PowerPC and
2015-07-02 Jenkinsと完全にサヨナラして、CircleCIに移行した話 CI Jenkins CircleCI 長らくCIはJenkinsを利用して開発をしてきて、Hudson時代からご愛顧してきたのですが、この春から新しくスタートしたプロジェクトではJenkinsを利用しないという決断をしました。 Jenkinsとサヨナラした理由 複数プロジェクトで共有して利用するのがツライ うちの会社では共通で用意されたJenkinsがあって(それなりにスペック高くて、slaveもぶら下がってる)、色々なプロジェクトがそれを利用しています。 このケースの問題点は何よりもランタイムやSDKを共有してしまうことにあります。全てのビルドに副作用を与えることなく、ランタイムやSDKを追加・更新するのが簡単ではありません。それを滞りなくやるには事前にどのビルドが何を使っているかを把握したり、利用
以前のエントリ( http://knjname.hateblo.jp/entry/2014/05/03/190842 )で自分でJenkinsのDockerイメージを作成したりしてみましたが、 Jenkins公式でDockerイメージを配布するようになったので、それを使用したほうがいいと思います。 Github https://github.com/cloudbees/jenkins-ci.org-docker DockerHub https://registry.hub.docker.com/_/jenkins/ 普通に使うだけなら、下記のようにすればいいだけですが、 docker run -p 8080:8080 jenkins これだと何も細かいことを設定できていないので、いくつか補足。 Dockerイメージ内のJenkinsのバージョンについて 永続化ディレクトリ(JENKINS_
著者の @kaz_29 さんから「CakePHPで学ぶ継続的インテグレーション」を献本して頂きました。日頃から関心のある分野なので、早速読ませて頂きました。 PHP で学ぶ継続的インテグレーション 本書のタイトルは「CakePHPで学ぶ継続的インテグレーション」です。実際、本書の中では、CakePHPアプリケーションを題材に継続的インテグレーションを行う手法が解説されています。 ただ、ここで紹介されている継続的インテグレーションの手法は、CakePHP 固有のものではなく、他のフレームワークでも転用可能なものです。 勝手なお世話ですが、書籍のタイトルとしては、「PHPで学ぶ継続的インテグレーション」の方が、良かったかもしれませんね:D 分散された情報がこの一冊に 継続的インテグレーション(CI)を行うには、あるツールさえ入れておけばできるというものではなく、多くのツールを組み合わせる必要が
Web技術について横断的に語り合うイベント「CROSS 2014」が1月17日、都内で行われました。 そのセッションの1つ「現場に聞く!テスト/CI/DevOps、実際のところどうなの」では、フリーランスエンジニアの伊藤直也氏がセッションオーナーとして司会を担当し、クックパッドで開発まわりのエンジニアをしている舘野祐一氏、はてなでアプリケーションエンジニアをしている伏井洋平氏、KAIZEN platform Inc.の石橋利真氏らがスピーカーとして登壇。 先進的な現場でテストやCIがどのように行われ、エンジニアのチームがどのように情報共有をしているか、本音で語るという注目すべき内容でした。本記事ではそのダイジェストを紹介しましょう。 現場に聞く!テスト/CI/DevOps、実際のところどうなの 伊藤 今日のテーマとしてはCI(Continuous Integration、継続的インテグレー
ASCII Booksのサイトをご利用いただき、ありがとうございます。 2016年12月6日をもちまして、サイトを閉鎖させていただくことになりました。 今までサイトをご利用いただき、ありがとうございました。 アスキー・メディアワークスを引き続き、よろしくお願いいたします。
細かく書きたいけど、とりあえずメモだけ。 ステップ数が増ている なんらかの開発が行なわれている ステップ数が減っている リファクタリングが行なわれている? 単に仕様落ちしたコードが削除された可能性もある テストカバレッジが下がる テストが書かれていない ... ステップ数が増えている場合 テストが減っている ... ステップ数が変わらない場合 FindBugs 、 PMD 、 Android Lint の警告数が増えている 品質の低下、レビューが正しく行なわれていない CPD 警告数が増えている 品質の低下、レビューが正しく行なわれていない そろそろリファクタリングしたほうがいい Checkstyle 警告数が増えている 品質の低下、レビューが正しく行なわれていない Jenkins で継続的にビルドしたり、テストを行なうのは言うまでもなく大切だけど、こういった静的解析の数値をグラフ化してい
Subversion/Gitなどを使用したソースコード管理、Jenkinsを使用した継続的インテグレーション、様々なxUnitフレームワークを使用した自動テストなどをソフトウェア開発組織として実践することは、今日では、その開発組織の技術的な強みではありません。 それらを実践しないことが、ソフトウェア開発組織の「弱み」なのです。また、組織としてそれらの実践を推進しない、あるいはサポートできないマネージャも「弱み」となります。さらに、大規模なソフトウェア開発組織においては、それらのためのインフラ整備をプロジェクトごとに立ち上げなければならず、サポート部門が存在しないことも弱みとなります。※1 ※1 プロジェクトを始めるごとに、ソースコード管理やJenkins用のサーバの調達、OSから様々なツールのインストールを一通り行うためには、それなりの時間を要します。したがって、バックアップをも含めて環境
状況はかなり改善した 非同期、setTimeout, Ajax系はSinonJSで簡単に Swarm系のツールでDOMのテストも容易に 環境構築も非常に楽になった PhantomJSはバイナリもあるし、ビルドも簡単 Swarm系のツールならブラウザでURLへアクセスすればすぐテスト開始
ビルドシステム構築スキルの重要性 - 達人プログラマーを目指してに関連して、開発プロジェクトで決定しなくてはならないことの一つに、Antを使うかMavenを使うかという判断があります。この両者に関してはそれぞれに信者の方がいて宗教論争のようなところもあるのですが、実際どちらの方が人気が高いのでしょうか? Mavenの熱烈なファンの方もいる一方で、Maven地獄などという言葉もあるようにMavenでひどい目にあった人もいるようです。そういう人はAnt+Ivyの方が軽くてよいと言います。さらに、 議論:Mavenはビルドに適したツールか? などを見るとなんとなくMavenはいまいちな印象を受けてしまいますし、Springも当初Maven化するという予定であったのに、 Spring switching to Maven? Oh no, think twice! などの発言もあり、結局Spring
第1章 構成管理入門 はじめに なぜ今構成管理に注目するのか 本特集で扱う内容 サンプルの準備 第2章 Subversionによるバージョン管理入門 はじめに クライアント環境の構築 インポート チェックアウト ソースファイルの変更に関連する操作 チーム開発に関連する操作 おわりに 第3章 Subversionベストプラクティス はじめに 帰ってきたO先輩 コードライン編その1 メインライン コードライン編その2 コードラインポリシー コードライン編その3 プライベートバージョン サードパーティライブラリのバージョン管理 リリース編その1 リリース管理 リリース編その2 自動リリース 継続的インテグレーション 第4章 Maven2によるビルド入門 はじめに なぜMaven2なのか? Maven2のインストール まずは試してみよう さらに開発を進めよう 第5章 Maven2ベストプラクティス
最近社内で何かと話題になっている CI(継続的インテグレーション)ツール Jenkins を使ってみました。 プロジェクトの開発メンバー各々でデプロイを行うと、何かと設定ミスやビルド環境の違いにより、 思わぬトラブルや、余計な時間のロスを招いたりします。 そんなときは、Jenkins がスマートにビルドを行ってくれますので、このおじちゃんに頼ってみましょう。 Jenkins を導入 Jenkinsには、パッケージ形式とwar形式があるようです。 今回はビルドサーバにtomcatがインストール済みなので、war形式で導入します。 ビルドサーバにログインし、wget でwarファイルを取得します。 $ wget http://mirrors.jenkins-ci.org/war/latest/jenkins.war tomcatのwebappディレクトリにコピーし、Tomcatを起動します。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く