E2Eテストワークフローを高速化・安定化させる取り組み | ドクセル
スライド概要 GitHub Actions Meetup Tokyo #3 https://gaugt.connpass.com/event/317178/ このプレゼンテーションでは、サイボウズ社のGaroonのE2Eテストについて、GitHub Actions self-hosted runner 上で実行していたE2Eテストを高速化・安定化させるために取り組んだこと、E2Eテストワークフローの視点の改善アイディアについて話されます。GaroonのE2Eテストにおける実行時間とFlakyが問題となっており、その改善に取り組んだ内容が紹介されています。 おすすめタグ：GitHub Actions,E2Eテスト,self-hosted runner,Garoon,テストワークフロー
CIを高速化する技術⚡️ - 10X Product Blog
この記事は 10X アドベントカレンダー2023 という企画の1日目（12/1）の記事です。 こんにちは、10Xでソフトウェアエンジニアをしている 岡野（@operandoOS）です。 今回 10Xで3回目となるアドベントカレンダー企画の1日目をありがたく担当させていただきます💪 目次 目次 10X アドベントカレンダー2023ってなに？ さてさて、本題へ CIは絶対に速い方がいい CIを高速化するテクニックの紹介 キャッシュの利用 マシン性能の調整 ジョブの並列実行とテスト分割 最適なテスト分割 ジョブの実行順序・依存関係の最適化 不要なジョブ・ステップを削除する テストコードの実行速度を上げる 紹介したテクニックを活用した10XでのCI高速化事例 アプリのビルド時間の大幅短縮に成功！！ APIのテスト実行時間の大幅短縮に成功！！ CIを高速化するために日々取り組んでいること CI/C
ライブラリのアップデートを自動化した仕組みの紹介 - Classi開発者ブログ
こんにちは！学習動画・Webテストの開発を行っています エンジニアの daichi (id:kudoa) です。 この記事では、最近チームで導入したライブラリアップデートを自動化した仕組みとその経緯について紹介します。 なぜ自動化しようと思ったか サービスを開発するだけではなく、日々の運用も必要です。 その運用業務の1つとして、ライブラリのアップデートがあります。 これはサービスを運用する上では大切なことではありますが、日々ライブラリアップデートのPRをさばき続けるのも大変です。 その時間をできるだけ減らし、その分空いた時間をユーザーへの価値提供や将来の投資に充てるために、今回の自動化の仕組みを作成しました。 この辺りの話は以前勉強会でLTしたことがありますので、興味があればご覧ください。 作ったもの 前置きは長くなりましたが、凝ったものを作ったわけではありません。 作成したものはライブラ
GitHub Actionsでメインバージョンのブランチ維持
keep-main-version-branchというGitHub Actions Workflowを用意したので、これについて説明しておく。 GitHub Actionsを公開するときの文化として、v2やv3のように、メインバージョンの最新版にアクセスできるGitのrefを提供しておくという慣習がある。例えば、コードをcheckoutしてくるための公式GitHub Action actions/checkoutでは、uses: actions/checkout@v3 のように利用しろと説明されている。v3という名前付きのrefをつくる方法としては、v3ブランチをつくる、またはv3タグをつくる、という二種類の方法がある。 自分も次のように幾つかのGitHub Actionsを保守しているが、このメインバージョンのrefを維持する作業がリリースのたびに面倒だった。これを自動化したかったので、
GitOps とデプロイ - Mitsuyuki.Shiiba
昨日はトランクベース開発とデプロイについて書いたので bufferings.hatenablog.com この勢いで GitOps とデプロイも書いてしまうー。先に言っておくと、自分は GitOps の経験はない。でも、よさそうだなぁと思う手法なので、機会があれば挑戦してみたい気持ち GitOps? GitOps は2017年に Weaveworks の Alexis によって提唱された手法で、Kubernetes を対象としている Guide To GitOps Git のリポジトリーに入れてある設定ファイルを Single Source of Truth として、Kubernetes のクラスター管理とアプリケーションデリバリーを行う。上記の記事には次の4つの原則が書かれている システム全体が宣言的に記述されていること 正規の望ましいシステムの状態が Git でバージョン管理されている
Git-flow とデプロイ - Mitsuyuki.Shiiba
前回 は継続的にデプロイしてるよって話をしたので、その流れで今日からちょっと Git を使った開発フローに対するデプロイについて考えてみたいと思う。まず最初はやっぱり Git-flow からかな。と、その前に 前置き 自分は CircleCI だとどうなるかなぁとか考えながら書いてるけど、どの CI サービス・ツールを使っても大丈夫 自分の頭の中にあるのはウェブ系の自社サービス。スマホアプリとか組み込みとかは経験がないから分かんない どんな風にテストを実行するかみたいな話も面白いけど、今回は CI のことは忘れてデプロイだけ考える どのフローが良い・悪いという話ではない Git-flow ということで Git-flow 。この絵は有名ですね どこが始まりなんだろう？って思ったら2010年のこの記事みたい： https://nvie.com/posts/a-successful-git-br
GitHub Actions を使ってリリース時のあれこれを自動化する
GitHub Actions を使ってリリース時のあれこれを自動化する 結論 リリース時のタグとリリースノートを自動で生成するようにした リリース時に自分がやることは 動作確認 => Merge pull request を押すだけにした なぜやるのか Release ノートを手動で作るのは面倒 手動でやることには人為的なミスの恐れがある 面倒なことを続けるとモチベーションが低下する(これ重要) 要件 リリース リリースは週に1度行う リリース前に開発した PR をリストで見ながら動作確認をしたい PR のリストがそのままリリースノートに記載されて欲しい 自動化 タグの作成は手動でやりたくない リリースのための PR を手動で作りたくない リリース時のバージョンを手動で入力したくない 自動化の必要性を感じたきっかけ 都内でシステムエンジニアをしている itizawa です。 理想のブックマ
開発環境構築スクリプトのCIをGitHub Actionsで回す - プログラムモグモグ
小ネタですが、開発環境の構築はスクリプト化して、CIを回そうという話です。 開発環境を構築することは年にそう何回もあるわけではないですが、スクリプトを一発叩いて必要なツールが揃うようにしておくと便利です。私は素朴にシェルスクリプトで書いています。好きな言語で書けばいいと思いますが、macOSは将来的にRubyやPythonといったスクリプト言語を排除しようとしていて、不安ですね。Ansibleみたいなのを使ってもいいと思います。私はちょっと苦手で… あくまで私用のスクリプトなので使わないでください。 このスクリプトを叩いてしまえば、iTerm2やVim、tmux、自分のdotfilesの配置と言語処理系のインストール、Google ChromeやSlackのインストールを行ってくれます。モダンなプロジェクトならdockerさえあればいいんでしょうが、なかなかそういうわけにはいかないですよね
Ansible Playbook の CI をまわす - Qiita
この記事は、Ansible Advent Calendar 2018 の 7 日目の記事です。 ソフトウェアは変更に弱く壊れやすいものです。Ansible の Playbook も例外ではありません。本記事では Rust の生みの親である Graydon Hoare 氏のこちらの記事を参考に、Configuration as Code の開発プロセスに CI を導入した結果について述べます。 The Not Rocket Science Rule Of Software Engineering: automatically maintain a repository of code that always passes all the tests tl;dr Ansible における Role のテストフレームワークである Molecule はローカル/CI環境問わず Playbook の
Gitlab CIでDockerベースのサービス開発のCI環境を作る - Qiita
開発中のDockerベースのサービスのCI環境をAWS上にGitlab CIで一から作ることになったのでせっかくなので手順や気にしたこと、そのうち何とかしたいことなどをまとめました。 開発中のサービスについて だいたい以下のような構成のサービスの開発をしてます。そのため、構築するCI環境はDockerをbuildし、テストスクリプトを実行するといったものです。 マイクロサービス 各サービスごとのリポジトリ(リポジトリが複数ある) リポジトリはgitlab.comで管理 各サービスはDocker(1つのサービスが複数コンテナの場合はある) テストはテストスクリプトから一括で実行できるようラップされている ※ テストコードの中身・内容については今回は述べません。 リポジトリ：gitlab.com CIツール：Gitlab CI + Gitlab Runner CI環境：EC2 t2.small
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub上で構築するコードメトリクス計測基盤 / TECH STAND #9 GitHub