CI/CD革新 GitHub Script活用術 - enechain Tech Blog
はじめに GitHub Script概要 セットアップ context の中身 eSquare Liveでの活用事例 発生した問題 タグの打ち間違い releaseブランチが複数存在する場合のデプロイ先選択の複雑化 解決策としてのGitHub Scriptの活用 機能1 vX.Y.Zのタグがmainブランチのコミットハッシュと一致することを確認する 機能2 releaseブランチは最新バージョンのみ自動で検証環境にデプロイする 完成版スクリプト まとめ はじめに こんにちは、enechainでeSquare Liveを開発しているエンジニアの古瀬(@tsuperis3112)です！ 今回は、マニュアル依存になりがちなデプロイフローの問題を actions/github-script で解消した方法についてお話します。 eSquare Liveの開発では、効率的かつ信頼性の高い開発フローを維
Devin AIにテストを丸ごと書かせてCIがパスするまで作業してもらう方法
Devinとは、ソフトウェア開発におけるタスクを自動化・効率化してくれるAIエージェントです。2024年12月に正式リリースされました。 私が所属しているUbieにも先日導入されました。様々な作業ができますが、あるリポジトリで不足しているテストを書いてもらったところ、その便利さに感動して椅子から転げ落ちました。 本記事では、Devinの実際の使い方と、利用する上でのポイントを紹介します。 1. テストの作成をSlackで依頼する Slackで「これこれのテストを書いてほしい」と依頼すると、Devinがテストコードを生成し、GitHubに新しいPRを作ってくれます。 依頼例は次のとおりです。 こんにちは、 @Devin 以下の仕事をして - ubie-inc/リポジトリ名 repo にアクセスして - （テスト対象のパス） のテストを書いて - 次のテストの書き方を参考にして - foo/i
書籍『GitHub CI/CD実践ガイド』を読みやすくする技術
拙著『GitHub CI/CD実践ガイド』は内容だけでなく、読書体験にもこだわりました。AmazonやSNSでも読みやすいという声は多く、技術書としては珍しい観点で評価を得ています。 Amazonにおける「GitHub CI/CD実践ガイド」の読者レビュー 本記事では書籍の「読みやすさ」という切り口から、執筆の舞台裏を紹介します。 最高の読書体験を目指す 技術書の使命は、役立つ情報を届けることです。しかし筆者は役立つだけでなく、読んでいて心地よい書籍にしたいと考えました。そこでまず決めたのが「最高の読書体験を目指す」ことです。そして最高の読書体験を実現するため、次のような設計原則を定めて執筆しました。 シンプルにする：短い文章・簡潔なコード・直感的な図表へと磨き上げる ノイズを減らす：難しい表現は避け、読者を迷わせる要素は徹底的に取り除く テンポを重視する：読者の集中力を削がないよう、読ん
日本ではKubernetesやCI/CDなどが幻滅期に、インダストリクラウドやインフラ自動化は過度な期待。「日本におけるクラウド・プラットフォームのハイプ・サイクル」2024年版発表
日本ではKubernetesやCI/CDなどが幻滅期に、インダストリクラウドやインフラ自動化は過度な期待。「日本におけるクラウド・プラットフォームのハイプ・サイクル」2024年版発表 調査会社のガートナージャパンは、「日本におけるクラウド・プラットフォームのハイプ・サイクル：2024年」を発表しました。 ハイプサイクルとは ガートナーのハイプサイクルは、技術の登場から安定までを5つのステージに分けて説明したものです。5つのステージは、「黎明期」から始まり、「『過度な期待』のピーク期」「幻滅期」「啓発期」「生産性の安定期」まで。この途中で消えていく技術もあります。 同社はグローバルだけでなく国別などさまざまな切り口でハイプサイクルを発表しています。今回発表されたのは日本のクラウドプラットフォームにおけるハイプサイクルです。横幅の関係上、図を2つに分割しました。まずは前半部分。 黎明期にはFi
リリース頻度を毎週から毎日にしてみた - NTT docomo Business Engineers' Blog
目次 目次 はじめに NeWork とは リリース頻度変更の背景 それまでの運用 課題 実現方法 解説 日次でワークフローが起動するようにする main ブランチの HEAD にタグが付与されていなければ付与する develop に差分があれば main へのマージを自動で行う 細かな工夫点 main の内容を develop に自動で取り込む 祝日はリリースしないようにする 自動リリース・自動 develop → main マージの制御 Slack にリリース結果を通知する stg 環境に変更内容を通知する その他の考慮 上司への事前説明の省略 スプリントレビュー前のリリース リリースノート 品質面 リリース頻度を変えてみて おわりに はじめに こんにちは、NeWork 開発チームの藤野です。普段はオンラインワークスペースサービス NeWork のエンジニアリングマネジメントをしています
社内用GitHub Actionsのセキュリティガイドラインを公開します | メルカリエンジニアリング
この記事は、Merpay Tech Openness Month 2023 の4日目の記事です。 こんにちは。メルコインのバックエンドエンジニアの@goroです。 はじめに このGitHub Actionsのセキュリティガイドラインは、社内でGithub Actionsの利用に先駆け、社内有志によって検討されました。「GitHub Actionsを使うにあたりどういった点に留意すれば最低限の安全性を確保できるか学習してもらいたい」「定期的に本ドキュメントを見返してもらい自分たちのリポジトリーが安全な状態になっているか点検する際に役立ててもらいたい」という思いに基づいて作成されています。 今回はそんなガイドラインの一部を、社外の方々にも役立つと思い公開することにしました。 ガイドラインにおける目標 このガイドラインは事前に2段階の目標を設定して作成されています。まず第1に「常に達成したいこと
RustにおけるGitHub Actionsベストプラクティス - paild tech blog
こんにちは大櫛です。Travis CIがオープンソースプロジェクトで使いづらくなったり、Azure PipelinesからGitHub Actionsになった途端*1爆発的な流行が生まれたりと、CIサービスにおいてもここ数年で色々な動きがありました。 特に技術記事・ブログのトレンドや企業のリクルート向け資料を見ていると、GitHub Actionsの利用が進んでいるような印象を受けます。 今回はそんなGitHub Actionsについて、Rust projectで使う際に知っておいた方がいいことやactionを紹介していきます。 以下の情報は執筆時点（2023-02-19）のものに基づいています。閲覧時には無効・誤ったものになっている可能性がありますので、必ず最新の情報・状態を確認するようにしてください。 actions-rs（非推奨） まずはじめに、執筆時点では使用を控えた方がいいact
意識的に職位を下げる - id:onk のはてなブログ
僕はチーム join 時に、Docker は初手で剥がすし、GitHub Actions でやっているワークフローの全体像を把握するのを次に行う、というのを基本的にはやっている。これはシステム構成やデプロイ周りの全貌を把握するのが好きなのと、何かが起きたときにコレをやっているのといないのとで問題切り分けの精度に圧倒的な差があるからなんだけど、join 直後にやるのが最適解とは限らない場面もある。 チームの人員構成として、テックリード業を既に担っている人が居る場合、追加人員にはテックリード未満の「プラスの工数として数えられる戦力」となって欲しい。この戦力というのは、「目の前に積み上がった問題を一緒に解いて欲しい」という期待。問題と言うよりも、既にタスクになっているものを消化したい、という期待の方が大きいと思う。 そういう期待があるときには、ちんたら Docker を剥がしている場合ではなく、
CircleCI上のRSpecによるテスト実行時間を25min -> 12minに短縮する技術 - ANDPAD Tech Blog
株式会社アンドパッドのアカウント基盤チームでテックリードをしているid:shiba_yu36です。 最近自分のサイドプロジェクトとして、生産性を向上するために、CI実行時間の短縮化を行っていました。その結果、とくに時間のかかっていたCircleCI上のRSpecによるテスト実行時間を、25min -> 12minに改善できました。そこで今回はどのような流れでCIの実行時間を改善していったかについて、具体的に書いてみたいと思います。実行時間改善の勘所について参考になれば幸いです。 改善の流れ: CircleCIでボトルネック調査し、大きいボトルネックを解消する 実行速度改善の前に: Flakyなテストを一斉に直す 速度改善1: bundle installのキャッシュがうまく効いていなかった問題を修正 -> 4minの短縮 速度改善2: developブランチ以外ではカバレッジを取らないよう
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
[github actions] Reusable workflowsが実装されたのでざっとまとめ
追記 年末にこの記事の内容も含めてgithub actionsをどう再利用するか総まとめしたのでそちらも併せてどうぞ！↓↓↓ この記事について 2021/11/24についにgithub actionsにReusable workflowsが実装されました。 まずは簡単にドキュメントをさらいながらポイントをまとめていこうと思います。 そもそも何が嬉しいのか これまでのgithub actionsではworkflowからactionを呼ぶことは可能だったものの、workflowから別のworkflowを呼ぶことはできませんでした。 workflowがひとつだけの場合そう問題にはならないのですが、同じworkflowの記述を使い回したい場合にはこれが問題になっていました。 例えば下記のようなworkflowを複数のリポジトリで使う場合、actions/checkout@v2とactions/se
![[github actions] Reusable workflowsが実装されたのでざっとまとめ](https://cdn-ak-scissors.b.st-hatena.com/image/square/c25aa961962cebb0eedf758efaeafa7f67419db9/height=288;version=1;width=512/https%3A%2F%2Fres.cloudinary.com%2Fzenn%2Fimage%2Fupload%2Fs--yeJ2s6DH--%2Fc_fit%252Cg_north_west%252Cl_text%3Anotosansjp-medium.otf_55%3A%25255Bgithub%252520actions%25255D%252520Reusable%252520workflows%2525E3%252581%25258C%2525E5%2525AE%25259F%2525E8%2525A3%252585%2525E3%252581%252595%2525E3%252582%25258C%2525E3%252581%25259F%2525E3%252581%2525AE%2525E3%252581%2525A7%2525E3%252581%252596%2525E3%252581%2525A3%2525E3%252581%2525A8%2525E3%252581%2525BE%2525E3%252581%2525A8%2525E3%252582%252581%252Cw_1010%252Cx_90%252Cy_100%2Fg_south_west%252Cl_text%3Anotosansjp-medium.otf_37%3AJerome_1010%252Cx_203%252Cy_121%2Fg_south_west%252Ch_90%252Cl_fetch%3AaHR0cHM6Ly9zdG9yYWdlLmdvb2dsZWFwaXMuY29tL3plbm4tdXNlci11cGxvYWQvYXZhdGFyL2Q1MWM1YjRlYzkuanBlZw%3D%3D%252Cr_max%252Cw_90%252Cx_87%252Cy_95%2Fv1627283836%2Fdefault%2Fog-base-w1200-v2.png)
Software Design連載 2021年9月号 「テストが無い」からの脱却 - MonotaRO Tech Blog
こんにちは、鈴木です。 「テストが無い」状態を脱却しました。 「いつの時代かよ！」と突っ込まれるかもしれませんが、モノタロウは創業から 20 年ほど EC をやっています。昨日書いたコードも、15 年前に書いたコードも、元気にビジネスを支えています。 本記事ではモノタロウの EC を支える API の話をします。「テストが無い」状態がスタートラインでした。そこから、CI を導入して、ローカル開発環境の整備して、テストコードを書いて、リリースマネジメントを導入しました。 目新しいことは書きません。長寿の大規模システムであっても、愚直に数年取り組むことで、「前進できる！」「変えられる！」という実例を書きます。 ※本記事の初出は、 Software Design2021年9月号「Pythonモダン化計画（第2回）」になります。第1回の記事は「Software Design連載 2021年8月号
Rails開発でやっておくと良かったCI設定集 - STORES Product Blog
STORES 予約 でwebアプリケーションエンジニアをやっております。ykpythemindです。 Rails開発で、どのようなアプリケーションでも抑えておくとチーム開発が少し楽になるポイントがあります。今回はいくつか実例を載せながら紹介します。 アプリケーションの設計的な部分や実装には踏み込まず、すぐに導入できます。 あくまでRailsアプリケーションについての記事ですが、他言語やフレームワークを用いていても同様のことができます。 1. シードデータが壊れないようにCIで担保する 新しいメンバーが入って環境構築をしてもらう度にシードデータが壊れており、 db/seeds.rb *1 を直すという作業を何回か経験しています。db/seeds.rbで実行する内容をテスト中に実行しておくとメンテされるようになります。 # db/seeds.rb # 定数データが必要であればここで呼ぶ req
CIのシークレット変数に1Password CLIを利用する - 24/7 twenty-four seven
CIでいろいろなタスクを自動化していると、CIで必要とするAPIのトークンやアカウント情報など設定しているシークレット変数が増えてきます。 たいていの場合はCIサービスのシークレット変数を利用すればよいですが、サービスによっては一度設定したシークレット変数を見ることができなかったり（GitHub ActionsやCircle CIが該当）、トークンやアカウント情報の更新や追加があったときにCIの変数を更新していくのが大変だったり、シークレット変数のメンテナンスはそこそこ面倒な作業です。 性質上かなり強い権限が設定されているトークンだったりすることもあるので、誰がその値をメンテナンスできるか、という管理の問題もあります。 そこで1Passwordをアカウント情報の共有に使っている組織なら、1PasswordはCLIの操作が提供されているのでCIから1Passwordのアカウント情報を取得する
マイクロサービス移行後のテスト、CI/CD、運用監視で現場が疲弊しないためのポイント
マイクロサービス移行後のテスト、CI/CD、運用監視で現場が疲弊しないためのポイント：特集：マイクロサービス入門（終） マイクロサービスアーキテクチャへの移行を進める上で生まれた課題にどう取り組んだのか。オイシックス・ラ・大地の川上徹氏がOisixのマイクロサービス移行後のテスト、CI/CD、運用監視を紹介します。 これまでの連載では、ECサイトであるOisixをマイクロサービスアーキテクチャへ移行させていくアプローチについて解説してきたが、今回は移行させた後の開発・運用について解説する。 併せて前回まで触れてこなかった開発時に留意しておいた方がいい継続的なメンテナンスや運用に関する内容についても解説する。 CI/CDパイプラインを生かした機動力のある開発 本連載の第5回でも「パイプラインファースト」という言葉について説明したが、開発当初からCI/CD（継続的インテグレーション／継続的デプ
CIマニアから見たGitHub Actions(Beta)の使い所 - くりにっき
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が詰まってジョブが実行され
Bitrise + fastlane で自動化していることを紹介します - LIVESENSE ENGINEER BLOG
デイキャンプとカメラにハマっているネイティブアプリグループの堤下(@roana0229)です。 みなさんはCI導入していますか？ 今まで弊社のiOS,AndroidアプリではCIが導入できていない現状がありましたが、2月末にリリースしたマッハバイトiOS版の開発を機に導入して、自動化していることを紹介します。 CIサービスは色々ありますが最近はよくBitriseを導入しているのを見かけます。ビルド環境への対応の早さやGUIでの操作しやすさから弊社もBitriseを導入しました。 静的なチェックの自動化 UnitTest以外では、静的なチェックでdangerを利用しています。dangerではgitの差分が扱いやすいようになっています。例えば、Swaggerを利用していてるのでAPI定義のyamlとswagger-codegenによって生成されるコードの差分をチェックしています。 swagge
Rails のテスト実行時間を60分から6分に短縮するまで - SmartHR Tech Blog
こんにちは。SmartHR のエンジニアの @meganemura です。 SmartHR はひとつの Rails アプリのリポジトリで開発が進められており、GitHub への Pull Request 作成などを契機に CircleCI でテストの実行や静的解析によるコード品質のチェックを継続的に実施しています。 しかし、プロダクトの成長と共に CI の実行時間が増え、またエンジニアの増加につれ CI のキュー待ちの時間も増え、実行完了までの時間が日々増え続けています。 その状況に対して、 Buildkite という CI サービスを利用して CI 環境の速度を改善した取り組みについて紹介します。 背景 以前にこのテックブログの CircleCI 2.0 の利用 の記事を公開した時点で全体のテスト実行が 40 分弱程度になっていたのですが、現在 50 分弱から 60 分程度にまで増加して
Gitlab CI を使ってみるメモ - ngyukiの日記
Jenkins からの移行のために今更だけど使ってみたメモ。 なお、うちの Gitlab はソースから入れていてデータベースも MySQL です。たまにしかバージョンアップしていないのでちょっと古いです(8.17.2)。 参考 https://docs.gitlab.com/ee/ci/ 公式のドキュメント https://docs.gitlab.com/ee/ci/yaml/README.html .gitlab-ci.yml のリファレンス https://docs.gitlab.com/ee/ci/runners/README.html Runner のドキュメント https://docs.gitlab.com/runner/ 公式の Runner の実装のドキュメント https://gitlab.com/gitlab-org/gitlab-ci-multi-runner ↑のリ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Jenkins X - Cloud Native CI/CD Built On Kubernetes
