GitHub ActionsのJobが落ちたときに何をするべきかを記述するPlaybookの仕組みを作って運用している話 - newmo 技術ブログ
newmoではGitHub Actionsを自動テスト、Lint、デプロイなどに利用しています。 また、newmoではmonorepoで開発しているため、1つのリポジトリに複数のチーム/複数のアプリケーションが存在しています。 GitHub Actionsではpathsを使うことで、特定のファイルが変更された場合のみ特定のWorkflowが実行できます。 newmoのmonorepoのworkflowでは基本的にpathsが指定されていますが、それでも普段は触らないファイルを変更して意図せずにCIが落ちることがあります。 GitHub ActionsのCIが落ちたときに、そのCIの仕組みを作った人やチーム以外だと何をすべきかわからないことがあります。 この問題の解決するを手助けするシンプルな仕組みとして、GitHub ActionsにCIが落ちたときに何をするべきかを表示するPlayboo
GitHub Actions のみで、actions/cache も使わない最軽量の VRT
Web アプリケーション開発での VRT 導入は、ちゃんと運用するとなると以下のような多くの検討事項を伴います。 Storybook のストーリーベースで比較するか？それとも実アプリケーションの URL ベースで比較するか？ CI 上でアプリケーションをビルドして dev server を立ち上げるか、それともデプロイ先のアプリケーションにアクセスするか？ スクリーンショットの比較はどのように行うか？比較時の閾値はどのように設定するか？ 比較元のスクリーンショットはどのように用意するか？例えば Amazon S3 などのストレージ や GitHub Actions の actions/cache を使用する場合など コミットハッシュを用いて比較元のスクリーンショットを特定する場合、マージ先のコミットハッシュに紐づくスクリーンショットが存在しない時の対応は？ VRT の結果で差分が出たが、そ
AWS DevDay Japan 2022 に「AWS CDKでECS on FargateのCI/CDを実現する際の理想と現実 」というタイトルで登壇しました #AWSDevDay | DevelopersIO
はじめに CX事業本部の佐藤智樹です。 先日AWS DevDay Japan 2022 というイベントで「AWS CDKでECS on FargateのCI/CDを実現する際の理想と現実」というタイトルで登壇しました。 今回は上記の登壇で使用した資料の公開と発表の補足を記載いたします。 登壇動画 登壇資料 発表理由 1年前に上記の構成を始めた際に、思っていたよりは理想の状態にできないことが多々あり、情報も多くないように感じたので少しでも参考になるように実践例をベースにまとめました。同じような構成を試される際は参考になるかと思います。また発表の1ヶ月以内(2022/09~10)に結構更新があったので、昔同じ構成試してダメだった部分があったかたも参考になる部分あるかと思うのでみてもらえると嬉しいです。 最後に 本当は資料90ページぐらいになってタイトルと関連性の薄い内容（ECS on Farg
Docker創始者らが開発、ビルド／テスト／デプロイの自動化をポータブルにするツール「Dagger」登場。そのままローカルでもGitHubでもCircleCIでも実行可能に
Docker創始者らが開発、ビルド／テスト／デプロイの自動化をポータブルにするツール「Dagger」登場。そのままローカルでもGitHubでもCircleCIでも実行可能に Dockerの創始者であるSolomon Hykes氏らが中心となって開発しているオープンソースのCI/CD環境構築ツール「Dagger」が公開されました。 Windows、Mac、Linuxで試すことができます。 And we are live! Introducing Dagger, a new way to build CI/CD pipelines. By the creators of Docker. https://t.co/DU8racmoUo — dagger (@dagger_io) March 30, 2022 Daggerが定義したCI/CDパイプラインはポータブルになる Daggerとは「A P
Terraform の CI を AWS CodeBuild から GitHub Actions + tfaction に移行しました - スタディサプリ Product Team Blog
こんにちは。 SRE の @suzuki-shunsuke です。 Terraform の CI を AWS CodeBuild (以下 CodeBuild) から GitHub Actions + tfaction に移行した話を紹介します。 これまでの Terraform Workflow (CodeBuild) 弊プロダクトの Terraform の CI に関しては過去の記事でも何度か紹介していますが、 元々 CodeBuild 上で CI を実行していました。 かつては CircleCI 上で実行していましたが、 CodeBuild に移行しました。 blog.studysapuri.jp CodeBuild に移行した理由は大きく 2 つありました。 Security 永続的な Access Key を発行することなく AWS のリソースを管理できる GCP に関しても Wor
数時間かかる週一リリースを毎日何度も爆速でできるようにするまで / CI/CD Conference 2021
CI/CD Conference 2021
Fulfilling the promise of CI/CD - Stack Overflow
[Ed. note: While we take some time to rest up over the holidays and prepare for next year, we are re-publishing our top ten posts for the year. Please enjoy our favorite work this year and we'll see you in 2022.] A Morality Tale Once upon a time there was a large and terrifying pirate ship, and it ruled the high seas despite being a bit leaky. The crew often had to pump seawater out of the lower d
CI/CDは何がまずいのか、コード作成から本番デプロイまでの時間短縮に注力
オブザーバビリティツールを手掛けるhoneycomb.ioの共同創業者でCTO（最高技術責任者）を務めるチャリティ・メージャーズ氏が2021年1月19日（米国時間）、開発者向けのQ＆Aサイト「Stack Overflow」のブログに記事を寄稿し、コード作成から本番環境へのデプロイまでの時間の短縮にフォーカスしてCI/CD（継続的インティグレーション／継続的デリバリー）に取り組むべきだと提言した。 以下では、メージャーズ氏の主張の概要を紹介する。 CI/CDは導入が進んでおり、特にCIはこの10年で取り組みレベルが向上している。だが、その一方で、CDは立ち遅れている。 CI/CDはプロセスと方法論を指す用語だ。メインリポジトリにマージした全てのコードをテストし、いつでも本番環境にデプロイ可能な状態にしておき、自動的にデプロイできるようにする設計を目指す。 CI/CDの目標はソフトウェア変更の
新卒１年目が荒れ果てた開発環境に１年間でCIを導入し単体テストを布教した話 - Qiita
この記事は 「Develop fun!」を体現する Works Human Intelligence Advent Calendar 2020 21日目の記事です。 昨日の記事は@sparklingbabyさんのStream API がもっとわかる記事でした。 あらすじ 私は2019年にWorks Human Intelligence（正確には分社前の会社）に新卒入社し、 19年10月からプロダクト開発部門に配属され、SETエンジニアとしてとある製品のJava開発環境の改善に取り組んでいます。 ざっくりとプロダクト開発を紹介するとこんな感じです。 3万クラス程度ある大規模Java Webアプリケーション 開発環境はEclipseを使用 開発者のOSはWindowsのみ Before 私が開発チームに参加した時点では 部門として新規開発に注力しており、足下の環境改善をやる担当者がおらず、 い
Postman をチームで運用していくためにフォーク機能を使ってみた - Techtouch Developers Blog
バックエンドエンジニアの misu です。TENET や羅小国戦記などわりと映画を見て最近は楽しんでいます。この記事を完成させたらクイーンズ・ギャンビットを見たいところ。。！ この記事について 前回、Postman を使って E2E テストを行う記事を書いたのですが、チームで運用してくとなると少し工夫が必要になったのでその辺の Tips を書いて行きます。 具体的には Postman のコレクションを git のようにフォークして、各開発者が開発ブランチごとに E2E テストを回せるようにしました。 内容 背景 下記図のように複数の開発者が1つのコレクションに対して、API を登録すると E2E のときに A は users API がないため CI が落ちてしまいます。B もまた然り。 本当に E2E 含め開発完了しているかは、落ちた E2E の結果を見て、開発スコープ以外のものだったら
SonarQubeで継続的インスペクションをはじめよう！ - 亀岡的プログラマ日記
これはギルドワークスイベントカレンダー 6日目の記事となります。 SonarQubeとは SonarQubeは皆さんご存知でしょうか？ もちろんメジャーなソフトウェアではあるのですが、Jenkinsなどの継続的インテグレーションツールなどと比べると、まだそんなに知られていないのかなと思います。 SonarQubeは、そのホームページに解説されているように、"Continuous Inspeciton"、つまり「継続的コードインスペクション（検査）」ツールです。 コードインスペクションは、言ってしまえばコードレビューの一種です。一般的には、コーディング規約の遵守チェックなど、より詳細なチェックを行うものを指します。 そのような詳細なチェックを人手でするのはかなり大変で、コード全体に継続的に行うのはかなり大変です。 そういう大変な作業を行ってくれるのは、SonarQubeです。 SonarQu
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
