You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
はじめに 以前からユニットテスト/単体テストという言葉は使いづらい、と感じており今回も旧Twitterで「テストを実行時間ベースで分類する良い言葉ないかなー」と呟いていたところ、「テストサイズのSMLって考え方があるよ」と教えて戴きました。 だいたいは教えてもらったt_wadaさんの記事にすべて書いてあるのですが、自分の整理も含めて動画にしたので、その補完記事となります。 TL;DR 単体テストのバベルの塔は既に崩壊 CI/CDでの継続的テストには時間ベースのテスト分類が重要 UT/IT/E2EではなくSMLによるテストサイズがCI/CDには合う それは単体テストか結合テストなのか? 自動テスト、手動テストに関わらずテストの分類として単体テストと結合テストという言葉は一般的です。 ITQBではTest Levelsという言葉で定義されていますし、以下のようなV字モデルの対応表はみんな知って
こんにちは。X(クロス)イノベーション本部 ソフトウェアデザインセンター の山下です。 今回はユーザーに合わせてオートスケールするGitHub ActionsのRunnerについて紹介しようと思います。 課題と目的 公式の推奨している方法について 構築の手順 事前準備 terraformの実行 terraformファイルの作成 terraformの実行 GitHub Appにhookの設定を追加 実際に利用する場合 まとめ 課題と目的 GitHub Actionsを使ってCIを実施するのは一般的になってきています。 ISIDでもGitHub Actionsを活用してCIを実施しています。 しかし、GitHub社が提供しているrunners(GitHub-hosted runners)では困る場合があります。「GitHub Actionsでオンプレミス環境のCI/CDを実行する方法」の記事で
はじめに Dockerfile、サッと書こうと思ったのに、書き始めたら意外と時間かかったりしますよね。 突き詰めるとすごく奥が深いなと思います。 公式のドキュメントでも、Dockerfileのベスト・プラクティスという形で公開してくれていますが、 これを毎回意識するのは大変です。 また、意識できていたとしても、複数人で管理していると、各個人のスキルレベルによって差が出てしまいます。 そんなときにおすすめのツールを見つけたので紹介します。 hadolintというツールです。 Haskell Dockerfile Linterの略だそうで、Dockerfileの静的解析を行ってくれるlintツールです。 hadolintを使うとこんな利点があります。 build前にシンタックスエラーなどに気付ける (地味にトライアンドエラーしてると時間食うんですよね...) 自然とベストプラクティスに則ったD
はじめに スタートアップ等において新しいプロダクトを始める時は、負債が無い代わりに何もありません。 そういった時に、ソフトウェアの品質を担保するための CI のセットアップが、初期から重要になってきます。 GitHub を使用している場合は、GitHub Actions を使用されることが殆どだと思うので、そちらを前提に進めていきたいと思います。 1. rhysd/actionlint 様々なエンジニアが action を追加したり、編集したりするようになった時、全員が正しい書き方で書いていくことは難しいです。 また、それを 1 人の GitHub Actions Expert がレビューしていくのは大変で、属人化してしまっているので、避ける方が望ましいです。 以下をコピペすれば、使用できます。 name: Actionlint on: push: branches: [ main ] p
つくったアプリケーションのソースコードは公開したい、でもシークレットはどうにかして秘匿しないといけない。継続的な運用を目指すならシークレットのデータ自体もなんとかしてリポジトリに(Repository secrets などではなくコミット対象として)含める必要がある。 …という状況を解決するために、gpg だけを使って継続的な運用を図る手段をまとめてみます。フロントエンド/バックエンドなど問わずどこでも使用できます。 Web フロントエンドなどから各種 API キーを利用する場合、リクエスト時の挙動はデベロッパーツールで全て確認できてしまう点には留意してください。 これらは API サーバー側でオリジンの制限をかけるなどの検討が必要です。 やること主な作業内容の要約は gpg を使ってプッシュする前にローカル側で暗号化をする暗号化するときに復号化のための(最強の)パスフレーズを登録するその
GitHub を学ぶときに「GitHub Learning Lab」を使うと便利!という紹介記事を6月に書いた.最近 GitHub Actions を使う機会があり,入門するために「GitHub Learning Lab」の「GitHub Actions: Hello World」コースを受講した.今回も非常に良かった! kakakakakku.hatenablog.com GitHub Actions: Hello World 「GitHub Actions: Hello World」は GitHub Actions を学ぶ入門コースとなる.現在はまだ日本語に翻訳されてなく,英語を選択する必要はあるけど,Bot / Issue / Pull Request を活用したインタラクティブな構成になっていて,楽しく学べる.以下のステップを進めていくことになり,最終的には GitHub Acti
Transcript XFCQBDLͱྑ͘ͳΖ͏ 8F�"SF�+BWB4DSJQUFST��!��UI None XFCQBDLͱྑ͘ͳͬͯ ͞Βʹ։ൃޮΛ ͋͛ΔΑ͏ʹͳΔͨΊͷࢿྉͰ͢ XFCQBDLͱྑ͘ͳΔલʹ ใΛݟ͘͢͢Δ ಛʹͳʹઃఆ͠ͳ͍߹ ͜ͷ··ͰݟͮΒ͍ XFCQBDL�EBTICPSE IUUQT���HJUIVC�DPN�'PSNJEBCMF-BCT�XFCQBDL�EBTICPBSE CFGPSF BGUFS Կ͕ΕΔͷ͔ w� -PH��ϏϧυϓϩηεͱΤϥʔϩάͷه� w� 4UBUVT��Ϗϧυϓϩηεͷεςʔλε� w� 0QFSBUJPO��ϏϧυϓϩηεͰൃੜ͢Δಛఆͷૢ࡞� w� 1SPHSFTT��Ϗϧυͷਐḿঢ়گ� w� .PEVMFT��ϞδϡʔϧϦετҰཡʹαΠζͱόϯυϧαΠζ� w� "TTFUT��Ϗϧυ
ある日、 PR の内容を見ずにマージすることを岡島(ピッチャーの)というらしい 笑った— いのうえ (@a_know) 2015, 9月 10 ということで、脳天気に笑っていたら、 @a_know むしろイキナリmasterリポジトリに直接pushするパターンですね!— そーだい@初代ALF (@soudai1025) 2015, 9月 10 という話になり、そしてなぜだか、 @a_know push -fと同様、Gitの運用アンチパターンとかどこかに纏めがほしいですねー。 #ブログ待ってます— そーだい@初代ALF (@soudai1025) 2015, 9月 10 というはなしになったので、本当に必要として頂いているのかどうかはともかく、 Git / GitHub でぼくやぼくの職場で気をつけていそうなことをまとめてみる。 もくじ もくじ GitHub Flow に沿って開発する 基本
こんにちは、開発担当の松本です。 前回のプラグイン紹介記事がわりと反響があったようですので、今回も便利プラグインをいくつか紹介します。 好みのテーマに変更できる: Simple Theme Plugin 左下のいつも出ている執事の顔が気になってくる人は多いと思います。 そんなときにはこのプラグイン。CSS と JavaScript を挿し込むだけの単純なプラグインながらその効果は絶大です。 利用するには、プラグイン導入後に Jenkins の管理 → システムの設定 → theme に追加する CSS と JS を指定するだけです。 プラグインのページにはサンプルのCSSファイルも用意されています。 とりあえず、執事の顔を消したいだけなら CSS に次のように記述すればよいです。 #main-table { background-image: none !important; } ページの
simple, flexible, fun Mocha is a feature-rich JavaScript test framework running on node and the browser, making asynchronous testing simple and fun. Mocha tests run serially, allowing for flexible and accurate reporting, while mapping uncaught exceptions to the correct test cases. Hosted on GitHub. Features browser support simple async support proper exit status for CI support etc auto-detects and
Jenkinsによる継続的インテグレーション ここ最近、継続的インテグレーション (CI)ツールであるJenkinsが大きな注目を集めている。継続的インテグレーションとは、ソフトウェアのビルドを定期的に実行することでコンパイルやテストが通らないといった問題を早期に発見するというものだ。CIは自動化されたビルドスクリプトさえ用意すれば開発言語を問わず導入することができ、既存の開発環境や開発プロセスにドラスティックな変化を必要とせずに導入できるため敷居も低い。 JenkinsはわかりやすいWebベースのインタフェースを備えており、手軽に導入できるという点が大きなメリットだが、ことオープンソースプロジェクトに関してはより手軽にCIを実現する選択肢が存在する。それがオンラインサービスとしてCIツールを提供しているTravis CIやBuildHiveだ。 Travis CIはオンラインCIサービス
はじめまして。エンジニアの岡崎(@watermint)です。今回はGREEにおけるJenkinsの利用について紹介します。 Jenkinsは継続的インテグレーションの代表的なツールです。JenkinsがどういうものかはJenkinsコミュニティーの説明をみると良く分かります。 一言で言えば、Jenkinsは、容易ないわゆる「継続インテグレーションシステム」を提供し、開発者が変更をプロジェクトに統合でき、ユーザーがより新しいビルドを容易に取得できるようにします。自動化された継続的なビルドは、生産性を向上させます。 Meet Jenkinsより 継続的インテグレーションという言葉について耳慣れないというかたは、JenkinsならびにJenkinsの前身であるHudson開発者である川口さんによる解説をご覧ください。 Hudsonを使ったアジャイルな開発入門 GREEにおけるJenkinsの導入
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く