【オフライン開催】Omotesando.rb #92 https://omotesandorb.connpass.com/event/302869/ Example code to skip tests if source trees are the same. https://gist.github.com/sinsoku/7b4201787d36f8ef669abd38395a28db
![CircleCIの高速化🚀 / CircleCI faster](https://cdn-ak-scissors.b.st-hatena.com/image/square/cf99ca0d2d31f399ba6a8c0b2c0a8c55fd33dd01/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Fae7710a943df41b3bf4a1b0f6fdcd868%2Fslide_0.jpg%3F28107302)
この記事は 10X アドベントカレンダー2023 という企画の1日目(12/1)の記事です。 こんにちは、10Xでソフトウェアエンジニアをしている 岡野(@operandoOS)です。 今回 10Xで3回目となるアドベントカレンダー企画の1日目をありがたく担当させていただきます💪 目次 目次 10X アドベントカレンダー2023ってなに? さてさて、本題へ CIは絶対に速い方がいい CIを高速化するテクニックの紹介 キャッシュの利用 マシン性能の調整 ジョブの並列実行とテスト分割 最適なテスト分割 ジョブの実行順序・依存関係の最適化 不要なジョブ・ステップを削除する テストコードの実行速度を上げる 紹介したテクニックを活用した10XでのCI高速化事例 アプリのビルド時間の大幅短縮に成功!! APIのテスト実行時間の大幅短縮に成功!! CIを高速化するために日々取り組んでいること CI/C
Chrome Web Store chrome.google.com 使い方ですが、GitHub PR pageに次のようにCI statusにcheckboxが現れるので、完了通知がほしいCI statusにチェックをつけるだけ。 チェックされたCI statusが完了(success or failure)になると、次のようなデスクトップ通知が出ます。この完了したときの通知をクリックすると該当のGitHub PR pageのタブをアクティブにします。 tab idごとにcheck状態をもっているので、リロードしてもtabごとのcheck状態は維持されます。 現在(v0.9.2)の機能はこれだけです。既知のバグとして、GitHubのPR画面で差分をみたりdiscussionに戻ったりしているとcheckboxが出ないことがありますが、そういう場合はリロードするとcheckboxが出ると思
CircleCIが無料枠を大幅拡大。1カ月あたり6000分のビルド時間、ユーザー数無制限、最大30件までのジョブ同時実行など CI/CD機能をクラウドサービスとして提供するCircleCIが、無料枠を大幅に拡大したことを発表しました。 At CircleCI our mission is to help teams deliver software faster and better. We’re so confident that you’ll be successful with CircleCI that we’ve added more features and more resource classes than ever before to our Free plan. https://t.co/oEuEREcTkv — CircleCI (@CircleCI) January
architect - システム設計 developer - システム開発 app-developer - アプリケーション開発 operator/sys-admin - 運用管理/システム管理 私が入社したころの弊社のリリースフローは、リリースブランチへの煩雑なcherry-pickの後、長いチェックリストやチケットを手動で更新した後、定期実行テストを待って次の日にデプロイ対象の変更をpushしたら、デプロイ対象のサーバー上で30分に一回実行されるcronでデプロイされるが、ランダムに失敗するので全台デプロイされるまでに数時間かかるというものでした。 あまりにも大変なのでリリースは多くても週一回しか行なわれず、変更粒度が大きくなるため毎度リスクが高いものになり、また何か起きた時もロールバックに時間がかかる厳しい状態でした。 今では、数百あるデプロイ対象の全てが当時とは異なるデプロイ方法に
CIでいろいろなタスクを自動化していると、CIで必要とするAPIのトークンやアカウント情報など設定しているシークレット変数が増えてきます。 たいていの場合はCIサービスのシークレット変数を利用すればよいですが、サービスによっては一度設定したシークレット変数を見ることができなかったり(GitHub ActionsやCircle CIが該当)、トークンやアカウント情報の更新や追加があったときにCIの変数を更新していくのが大変だったり、シークレット変数のメンテナンスはそこそこ面倒な作業です。 性質上かなり強い権限が設定されているトークンだったりすることもあるので、誰がその値をメンテナンスできるか、という管理の問題もあります。 そこで1Passwordをアカウント情報の共有に使っている組織なら、1PasswordはCLIの操作が提供されているのでCIから1Passwordのアカウント情報を取得する
【注意】この記事で紹介しているSMS APIサービスのVonageは利用規約により認証にVonageの電話番号を利用することを禁止しているという記述があるので、末尾の別解として載せたAndroidデバイスを使ってSMSを転送する方法が良さそうです。 help.nexmo.com 2021年2月から、App Store Connectにログインする際にすべてのApple IDで2ファクタ認証が必須になります。 Starting February 2021, additional authentication will be required for all users to sign in to App Store Connect. This extra layer of security for your Apple ID helps ensure that you’re the only
はじめまして。NRIデジタルの石井佑磨です。 「AWS re:Invent 2020」でEC2 Macインスタンスが発表されましたね!また、インフラストラクチャキーノートでは、Mac miniとNitroコントローラの組み合わせによって実現されたことが説明されました。これらは、みなさんも注目しているサービスではないでしょうか。 Macインスタンスのユースケース Macインスタンスのユースケースとして、Xcodeを用いたiOSアプリの開発があります。Macインスタンスを用いたCI/CDを実装し、既存のCI/CD環境との比較を行いたいと思っているのですが、今回は第1弾として、CI環境の構築のみを行います!Macインスタンスでなにかやってみたいという方、iOS開発に使えないか検討している方に読んでいただけると幸いです! ※本記事では、セキュリティやCI環境構築時の細かい操作などについては、他のブ
しっかり調査してないですが、こういったCIサービスがほぼ存在しない時期にほぼほぼ最初に登場して、一時期明らかにデファクトスタンダードだったと思うので、昔からOSS活動している人ほど、とても多く利用してお世話になっていたと思うので、そういう人であればあるほど、この状況は、怒りではなく、悲しいというか残念というか、辛いと思うんですよね・・・。 今までありがとう・・・。 長年Travis CI使ってきたので、GitHub Actionsによって潰される(のかどうなるのかわからないけど)、の可愛そう、という気持ちが若干あるけど、とはいえ、こういうのよくある話な気はするな…— Kenji Yoshida (@xuwei_k) 2020年10月7日 買収されて方針変わったのかなと感じるところもありますし、OSSプロジェクトが無料で使っていても会社としては辛いのではという気もするので今までの感謝の気持ち
EngineeringMaking GitHub CI workflow 3x fasterUsing deferred compliance in GitHub’s CI process to improve developer productivity. Welcome to the first deep dive of the Building GitHub blog series, providing a look at how teams across the GitHub engineering organization identify and address opportunities to improve our internal development tooling and infrastructure. At GitHub, we use the Four Key
GitHub Actionsのローカル実行ツール「act」を使う事でCI/CDコンフィグとローカルでのタスクランナーを1つにする actというローカル端末でのタスクランナーとしても使える、GitHub Actionsのローカル実行ツールを紹介します。 合わせて私のCI/CDのローカル実行ツールが必要だと思う理由、タスクランナーに対して感じている課題を紹介します。 はじめに おはようございます、加藤です。CI/CDツールとしてGitHub Actionsが2019年11月にリリースされてから一気に広まり、私もファーストチョイスとしてGitHub Actionsを検討・提案する機会が最近増えてきました。 先日、下記のTweetでactというGitHub Actionsのローカル実行ツールがあり、タスクランナーとしても使えるという事を知りとても興味を持ったのでブログにまとめました。 Actってい
先週仕事でやったのをメモします。 CI力が低いので、記事を公開することでツッコミをもらうのが目的です。 モチベーション 弊社ではCIの実行が1回あたり20分ほどかかっています。 これはわりとストレスなので速くしたいです。幸いにも削れそうなところが2つ見つかったので削ってみました。 Shallow Clone CircleCIではデフォルトのcheckoutを使用するとリポジトリの全体をcloneしてきます。 これを回避するためにshallow cloneを導入しました。 まず、次のようなコマンドを定義します。 commands: shallow-clone: description: 'Git clone shallowly' steps: - run: name: 'shallow clone' command: | set -x echo "machine github.com log
11月に入社したCTO室SREの@sinsokuです。 主にやっていることはRailsアプリのレビューや開発環境の改善です。*1 社内のRailsアプリを横断して浅くレビューする(8つくらい) MedPeerの開発環境の改善 docker-compose up で30個のコンテナが起動するのを減らす SwitchPointからActiveRecord v6への移行 CircleCIの実行時間の短縮、稀に落ちるテストの修正 その他の細かい改善 このうち、CircleCIについて知見が溜まったので技術ブログで紹介します。 CircleCIで気をつける点 CircleCIの実行時間を短くするにはいくつかコツがあります。 gemとnpmをできるだけキャッシュする RSpecを並列で実行する前に assets:precompile を実行しておく 各ジョブで必要なgem(もしくはnpm)だけをキャッ
2日間で30個くらいのリポジトリでGitHub Actionsに移行したのでメモ tl;dr; モチベーション GitHub Actionsを選んだ理由 GitHub ActionsでgemのCIをするための設定 2020/1/4 0:40追記 weekly build 公式のactions/setup-rubyではなくmasa-iwasaki/setup-rbenvを利用 ボツ案:Dockerイメージのrubyを使う masa-iwasaki/setup-rbenvを利用 setup-rbenvを使う場合の注意点 Travis CIのallow_failuresをGitHub Actionsでも実現する GitHub ActionsでRuby 2.3以下をビルドする Gemfile.lockをコミットしないリポジトリでもキャッシュを保存したい GitHub Actionsの不満点 ジョブ
GitHub Actions Advent Calendar 2019 の 15 日目の記事です。 この記事では、GitHub Actions のキャッシュ機能について解説します。 目次 CI/CD とキャッシュ 簡単な例 (npm) 実験用リポジトリ作成 キャッシュ actions/cache Inputs と Outputs キーのマッチング順序 ビルド失敗時 キャッシュクリア 複数 OS で matrix ビルドするときのキャッシュ 言語ごとの例 アーティファクトとキャッシュの違い 制限事項 注意事項 まとめ CI/CD とキャッシュ CI/CD のビルドでは、リポジトリが依存するパッケージのダウンロードが原因でビルド時間が長くなってしまうことがよくあります。近年の CI/CD ではビルドごとに完全にクリーンな実行環境が用意され、前回のビルドでダウンロードしたファイルが持ち越されない
やっときたので使ってみた。 CI マニアから見た GitHub Actions(Beta)の使い所 - くりにっき https://github.com/mizchi/frontend-gh-action-playground で素振りして挙動を確かめた後、会社の結構重めのリポジトリに突っ込んでみた。まだ 2 日目なので、実際そこまで経験値足りてない。 とりあえず困ったらここ読む GitHub Actionsのワークフロー構文 - GitHub ヘルプ 良い点 sue445 さんの記事でも書いてあるが、ジョブが 20 個まで並列になるので、並列に分解できるようなものに強い。 GitHub に完結してる点。checks タブで CI の結果が見える。 circleci.com/dashboard とか行かなくていい。外部 CI はアカウント取得やらリポジトリごとの設定やらなんやらもあるので、
1ヶ月くらい使って勘所が見えてきたのでメモ メリット 1リポジトリ辺り20並列までジョブを並列実行できる ジョブ実行時はアクセストークンが勝手に設定されている マトリクステストがやりやすい 実際にGitHub Actionsに移行したプロダクト zatsu_monitor activerecord-compatible_legacy_migration index_shotgun デメリット yamlのanchorが使えない マトリクステストだとSlack通知がつらい 合わせて読みたい メリット 1リポジトリ辺り20並列までジョブを並列実行できる これに尽きる。 CircleCIにしろTravis CIにしろorganization(user) *1単位で並列数が縛られているため、例えば同じuserの他のリポジトリでジョブが詰まっていると別リポジトリではqueueが詰まってジョブが実行され
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く