Content-Length: 286258 | pFad | http://b.hatena.ne.jp/babydaemons/CI/
zx + Datadog + GitHub Actions でフロントエンドのコードベースの健全性を可視化する
フロントエンドのダッシュボードを作ってみたらいい感じだったので紹介です。 作ったもの zx と Datadog、GitHub Actions を使って以下画像のように、フロントエンドのコードベースの各指標を可視化するダッシュボードを作りました。 値はデモ用に書き換えています 現在、計測している指標はこちらです。 Vue SFCファイルにしめるTypeScriptの割合 Vue SFCファイルにしめるComposition APIの割合 strict: trueにした場合のType Errorの数（tsc & vue-tsc） Jestの各種カバレッジ 各指標は毎朝9時に更新していて、時系列での推移も確認できます。 なぜ作った？ 技術的負債解消等コードベースのリファクタリングの活動は、機能追加に比べ進捗を把握しにくい、成果が伝わりにくいという問題があり、それを解消したいと考えたからです。 こ
MisocaのCI構成まとめ - 弥生開発者ブログ
こんにちは。4月からMisocaにjoinしました、tkykです。京都市内からリモートで働いています。盆地特有のねっとりとした暑さをやり過ごしつつコードを書いている今日この頃です。 さて、今回はMisocaのCI（Continuous Integration）環境がどうなっているか、その全体像を紹介したいと思います。 そもそもCIの目的とは？ ソースコードの一部に対する変更が、アプリケーション全体の動作を壊してしまっていないか、常時チェックするのが目的です。 そのために何をしているか CI専用のサーバに、変更点を含むソースコード全体をチェックアウトして、依存ライブラリのインストールと必要な前処理を行い、すべてのテストを実行します。 すべてのテストがエラーなくpassしたことをもって、CIが通ったとしています。 Gitを使った開発フローとの統合 MisocaはGitHub上で開発を行なってい
よいコミットメッセージ・よくないコミットメッセージ - 弥生開発者ブログ
こんにちは、mzpです。 今日はMisocaのesaに書いていた「よいコミットメッセージ・よくないコミットメッセージ」という記事を紹介したいと思います。 あらすじ 開発チームでは「コミットメッセージには変更理由を書いて欲しい」「コミットメッセージはWhatよりもWhyが大事」という話を何度かしているのですが、なかなか徹底できていません。 ので、もう少し具体的に「こういうコミットメッセージはよくないですね」というまとめを作ってみることにしました。 ちなみにこの過程でみつけたコミットメッセージに、こんなものがあります。 一切情報がなくておもしろいですね。 ファイル移動を移動した事実しか書かない これは以下のようなコミットメッセージです。 ファイル名を変更 ディレクトリを移動 ファイルを移動したことはコミットメッセージを見なくてもdiffから分かりますが、なぜその移動をしたかが分かりません。 の
Jenkinsとrrrspecと私 - 弥生開発者ブログ
Misoca開発チームの黒曜(@kokuyouwind)です。 最近PS VRを買いました。画像は夏にSony StoreのPS VR体験会へ行った際、スタッフの方が撮ってくださった写真です。 OculusやViveと比べると解像度は低めですが十分な没入感がありますし、なによりアイマスやVOCALOIDなどのキャラクターコンテンツが色々あるのは強いですね。 PS VRはいいぞ。 rspec-queueからrrrspecへの移行 MisocaではJenkinsを使ってCIを回しています。 またrspecでテストを書いており、Jenkins上では時間短縮のためにrspec-queueを使って並列実行していました。 しかし、テストが増えるにつれてrspecの実行時間が長くなってしまい、CPUコア数やメモリの制約で1ノード内での並列数も限界になっていました。 このため、ビルド時間の短縮を目的にrr
ブルックスの法則とはなにか - 未来のいつか/hyoshiokの日記
ソフトウェア開発におけるブルックスの法則とは何か。 http://ja.wikipedia.org/wiki/%E3%83%96%E3%83%AB%E3%83%83%E3%82%AF%E3%82%B9%E3%81%AE%E6%B3%95%E5%89%87 遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせる ブルックスはIBM System/360用オペレーティングシステムOS/360の開発総責任者だった人で、その経験をもとに人月の神話【新装版】というエッセーを執筆した。 人月の神話は、ソフトウェア開発を志す人なら必ず一度は読まなければいけない良書だ。読んでいない人は、悪いことは言わないから、ともかく読むことをおすすめする。 初版が出版されたのが1975年（日本語訳は1977年）で、20周年記念版が1995年に出た。ブルックスの発見した法則があきらかになって約40
はてなやクックパッドの開発現場で、CIやテストはどう行われているのか？（前編）。CROSS 2014 － Publickey
Web技術について横断的に語り合うイベント「CROSS 2014」が1月17日、都内で行われました。 そのセッションの1つ「現場に聞く！テスト/CI/DevOps、実際のところどうなの」では、フリーランスエンジニアの伊藤直也氏がセッションオーナーとして司会を担当し、クックパッドで開発まわりのエンジニアをしている舘野祐一氏、はてなでアプリケーションエンジニアをしている伏井洋平氏、KAIZEN platform Inc.の石橋利真氏らがスピーカーとして登壇。 先進的な現場でテストやCIがどのように行われ、エンジニアのチームがどのように情報共有をしているか、本音で語るという注目すべき内容でした。本記事ではそのダイジェストを紹介しましょう。 現場に聞く！テスト/CI/DevOps、実際のところどうなの 伊藤 今日のテーマとしてはCI（Continuous Integration、継続的インテグレー
継続的インテグレーションアンチパターン
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） 頻繁にSCMにコミットしないテストコードを書かないテストコードと製品コードを同時にコミットしない定時ビルドのみでコミットビルドがない・夜間ビルドしかない帰り際にコミットしてそのままCIの結果を見ずに帰るCIでテストを通すために手作業の準備が必要メインラインのみで大きなブランチをCI対象にしていない様々な種類のテストをまとめて行っているビルドの失敗に気付かないビルドに失敗しても放置しているビルドの失敗に気づいても、修正コード以外のコードをコミットする何も変更していないのにビルドが落ちたり落ちなかったりする頻繁にビルドが失敗しているので、失敗するのが普通だと思うCIからの通知メッセージが大量すぎるCIが落ちても何も通知しないCI
【書評】手動デプロイからの卒業指南書「継続的デリバリー」
継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化著者／訳者：David Farley、Jez Humble、和智 右桂、高木 正弘出版社：KADOKAWA/アスキー・メディアワークス発売日：2012-03-14大型本：544ページISBN-13：9784048707879ASIN：4048707876 レビューに参加させていただいた縁でアスキー・メディアワークス社様より献本いただきました。和智さん、高木さんの黄金コンビによる翻訳です。 デプロイ自動化に関する話を網羅的に扱った本はこれがはじめてでしょう。 上級技術者向けと書かれているように内容は結構ハイレベルで、構成管理、CI、テスト戦略についての前提知識が求められるように思いますが、アジャイルなプロジェクトの中で日々改善を繰り返している人たちにとっては理解しやすいのではないかと思います。 デプ
組織に継続的インテグレーションを導入していく7つの段階
みなさんこんにちは。@ryuzeeです。 継続的インテグレーションの導入に関する分かりやすい記事があったので抜粋・意訳にてご紹介します。 原文はJohn Ferguson Smart氏のブログ記事「The Seven Phases of Introducing Continuous Integration into Your Organization」です。 継続的インテグレーションは全部かゼロかといった類のものではない。事実、CIの組織への導入はいくつかの明確な段階を経て進んでいくのだ。それぞれの段階は技術的な構造もそうだが、それ以上に重要であるであろう開発チーム自体のプラクティスや文化のインクリメンタルな改善を含んでいる。 以下の章では各段階についておおよその全体像を示すことにしよう。 第1段階 ビルドサーバがない初期の段階ではチームはなんらの中央ビルドサーバも持ちあわせていない。ソフ
こくちーずプロ - 無料で使えるイベント・セミナーの告知・集客サービス
個人から法人まで幅広い主催者の方にご活用いただいています。 イベント主催者8万人以上 チケット販売550万枚以上
zusaar.com - このウェブサイトは販売用です！ - zusaar リソースおよび情報
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
第1回 Hudsonの導入 | gihyo.jp
継続的インテグレーションとは Hudsonの具体的な紹介に入る前に、まず簡単に「継続的インテグレーション」（Continuous Integration、以下CI）のおさらいをしましょう。CIは、Extreme Programmingに端を発し、Martin Fowlerによって広められた概念で、狭義には、別々に開発された部品を持ち寄ってお互いの動作を検証する「統合テスト」を早い段階から恒常的に行うことを指します。この当初の概念には必ずしも統合テストの自動化という考え方は含まれていませんでしたが、最近では、CIは単に統合テストだけではなく、広くビルド及びテスト全般を恒常的に行うことを指すようになり、またこれを現実的な工数で実現するための必須の手段として、ビルド・テストの工程を極力自動化する、という事が重要なポイントの一つになってきました。 この考え方の背景の一つには、コンピュータの高性能
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Fetched URL: http://b.hatena.ne.jp/babydaemons/CI/
Alternative Proxies:
日本語 : Jenkins