GitLab CIを使って仕事で楽をする - Qiita
初めまして。Qiitaにはいわゆる初投稿というやつです。今後も(あれば)よろしく。 軽い自己紹介 大学生やってます。後輩のコードレビューをする際に品質を下げずに楽をしたかったので、CIを用いることにしました。 この記事はJenkins等のCI環境を経験したことをなかった僕が手探りでやった内容になりますので、おかしい点があったら指摘してもらえるとありがたいです。 GitLabとGitLab CI ちょっとしたお話 GitLab CIはバージョン7までは設定したら使える、GitLab本体とは別の機能でした。 ですが、8にてGitLab本体と完全に統合された結果、特に設定しなくても有効になり、またUI面でも細かい部分が変化しています。既にあるブログの資料などが、若干runnerの扱いが異なったりするのはそのためです。 使う計算機資源 GitLab(Ver:8.4.2)用のサーバーが一台 CI R
GitLabでドキュメントのビルドとホスティング - Blank File
完全に思いつきで、GitLabでドキュメントをgit管理してCIでビルドしてGitLab Pagesで表示する、というのをやってみました。 GitLabはGitHubみたいなサービスです。 （というかGitHubクローンで、以前はあまりにも似過ぎてたためになんか色々あったらしい、というウワサをどこかで目にしたような・・・？） （そのせいかわかりませんが、プルリクエストはMerge Requestという名前のようですね・・・） GitHubでも似たようなことはできますが、 Travis CI（などのCIサービス）を使ってgh-pagesブランチにプッシュする Read the Docsを使ってそっちでビルド＆表示 などいずれにしろ別サービスとの連携が必要になってしまいます。 ローカルでhtmlを作って自分でpushすることもできますが、それは何か少し負けた気がするので却下です。 GitLab
Gitlab CIを使ってSphinxのドキュメントを自動でPDFにビルドする - once upon a time,
gitlab.comは自前でDocker image登録できたり、CI持っていたりと便利ですね。しかも、privateレポジトリもお金かからないという太っ腹。 技術書典2に向けたレポジトリはgitlab.comで管理しています。 今回は共著者にPython使いが多いためSphinxを使って書いているんですが、Sphinxはcommon markでも書けるのでmarkdownでも文章を書くことが出来ます。 前回の記事では、数式入りのmarkdownからPDFを生成するDocker imageを作りましたが、それを使うと簡単にGitlab-CIでPDFが生成できます。 chezou.hatenablog.com やり方は簡単、あなたのSphinxのプロジェクトに、以下のような.gitlab-ci.ymlを書くだけ。もちろん、必要に応じてpathsは変更してください。 image: chezou
プログラマーの三大美徳 その２
みなさんはプログラマーの三大美徳ってご存知ですか? プログラミング言語Perlの作者である Larry Wall が http://www.perl.com/pub/1998/08/show/onion.html で述べたのが最初とされています。 三大美徳として 怠惰(laziness) 短気(impatience) 傲慢(hubris) があげられています。 怠惰(laziness)については、以前にこちらの記事でお話しました。 tech.mercari.com 今回は 短気(impatience) についてです。 短気(impatience) 優秀なプログラマーが持っている怠惰という美徳は素晴らしいのですが、その反面というか怠惰さゆえに腰が重いときがあります。 そこで短気な面をうまく刺激することでプロジェクトを円滑に進めることが可能です。 メルカリでの例 みなさんもCIにてテストを動か
はてなやクックパッドの開発現場で、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、継続的インテグレー
Infrastructure as Code - naoyaのはてなダイアリー
今年の3月に 入門Chef Solo - Infrastructure as Code という本を書いた。 その名の通り Chef の入門書なのだけど、このサブタイトルは "Configuration Management Tool (構成管理ツール)" でもなく "Provisioning Framework (プロビジョニングフレームワーク)" でもなく、はたまた "Automated Infrastructure (自動化されたインフラ)" でもなく、"Infrastructure as Code" にした。 この一年で Chef や Puppet にはずいぶんと注目が集まった。おそらく、AWS をはじめとするクラウドサービスがより広いユーザーに浸透したことで仮想化環境が前提になって、以前よりも頻繁にサーバーを構築し直したりする機会が増えたとかその辺がひとつ理由として挙げられると思う
Travis CIとCoverallsとCode Climateを使ってGitHubリポジトリにバッジを付ける - アインシュタインの電話番号
先月に公開した超ニッチなツールFont Awesome Workflow for Alfred 2が意外と好評で、そこにオクラホマ州からこれOS X Mavericksで動いとらんよとお便りが届いたりした。 そんなわけで少々テストを書いた上で、Mountain Lion以前に入っているRuby 1.8.7と、Mavericks以降に入るRuby 2.0.0の両方で常に動作確認しておくようにしたいと考えて、まずTravis CIを、その後CoverallsとCode Climateを導入した。この記事はその備忘録。 {: .ArtcleBody-inlineImage .u-textCenter } それらを導入すると、こんなかんじのバッジを表示できる。GitHubでよく見かけるやつ。今回使ったサービスはどれも、オープンソースなら無料で使わせてもらえる。 Travis CIは名前の通り継続的
Rubyアソシエーション: Jenkins
継続的インテグレーション 継続的インテグレーションツールとは、バージョン管理システムにある最新ソースを定期的に取得してビルドおよびテストを実行し、テスト結果を出力するものです（参考）。継続的にテストを行うことで、システム全体の品質改善が期待され、統合に伴う問題を減らすことができます。ここでは代表的なツールであるJenkinsを使って、RSpecのテストコードを定期的に実行するための設定方法と結果表示を紹介し、継続的インテグレーションの概要を説明します。 以下の条件を前提とします。 ・Ruby1.9.3 ・Rails2.3.1 ・RSpec2.8.0 ・Subversionによるコード管理 1.対象とするアプリケーションの準備 既にRSpecのテストコードが含まれたアプリケーションがあれば、このセクションをスキップしても構いませんが、JenkinsでRuby1.9系を用いてカバレージを取得す
[Rails4,Jenkins] ci_reporter でテスト結果を整形
社内でもじわじわと Rails 4 の利用が広がっています。 弊社ではCIサーバに Jenkins を使用していますが、Rails プロジェクトのテスト結果を Jenkins で整形して表示するには、Ruby のテストフレームワークの出力を JUnit 形式の XML に変換してくれる ci_reporter が便利です。 しかし Rails 4 の場合、現状ドキュメントに書いてあるとおりに設定してもうまくいかないようです。そこで、試行錯誤してうまくいった方法をここで紹介します。なお、この記事で使用したバージョンは下記のとおりです。テストフレームワークは Rails 標準の ActiveSupport::TestCase を使います。 | Ruby | 2.0.0-p0 | | Ruby on Rails | 4.0.0.rc1 | | ci_reporter | 1.8.4 | | Je
![[Rails4,Jenkins] ci_reporter でテスト結果を整形](https://cdn-ak-scissors.b.st-hatena.com/image/square/8d71ff5111e05619a10d29bb40d7aebaa75c8fbc/height=288;version=1;width=512/https%3A%2F%2Fs0.wp.com%2Fi%2Fblank.jpg)
【入門】Jenkins (CI) + Ruby on Rails 3.2.x (RSpec) + GitHub + Amazon EC2 (Amazon Linux AMI) を使った継続的テスト【更新：2013-10-29】 - #tech
前置き 最近、扱っている Rails アプリケーションの規模が少し大きくなってきたので、 そろそろちゃんとテストを書かないとなぁと思っていた。 私はテスト (CI) に関して次のような考えを持っている。 テストの実行は第三者がおこなう 人はどうしても怠惰な方に流されやすい生き物だと思う。 私も「ちゃんとしっかりテスト（書いて・実行）しよう！」という意思が薄いタイプの人間に思える。 なので、テストの実行と、失敗時の通知は、自分ではない「第三者」がやってくれないと困る。 サボってたら叱ってくれる人がいてほしい。 テストの成功・失敗の履歴は残しておくべき テストがチェックインごとに正しく実行され、どのチェックインでテストが壊れたのか。 それはきちんと管理されているのが望ましいと思う。 いつの間にか、テストが壊れており、どのチェックインで壊れたのかわからない。 という状況は避けたい。 というわけで
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitLab CI ユーザーのための YAML 入門 - Qiita
Continuous Integration and Delivery - CircleCI