拙著『GitHub CI/CD実践ガイド』は内容だけでなく、読書体験にもこだわりました。AmazonやSNSでも読みやすいという声は多く、技術書としては珍しい観点で評価を得ています。 Amazonにおける「GitHub CI/CD実践ガイド」の読者レビュー 本記事では書籍の「読みやすさ」という切り口から、執筆の舞台裏を紹介します。 最高の読書体験を目指す 技術書の使命は、役立つ情報を届けることです。しかし筆者は役立つだけでなく、読んでいて心地よい書籍にしたいと考えました。そこでまず決めたのが「最高の読書体験を目指す」ことです。そして最高の読書体験を実現するため、次のような設計原則を定めて執筆しました。 シンプルにする：短い文章・簡潔なコード・直感的な図表へと磨き上げる ノイズを減らす：難しい表現は避け、読者を迷わせる要素は徹底的に取り除く テンポを重視する：読者の集中力を削がないよう、読ん
日本ではKubernetesやCI/CDなどが幻滅期に、インダストリクラウドやインフラ自動化は過度な期待。「日本におけるクラウド・プラットフォームのハイプ・サイクル」2024年版発表
日本ではKubernetesやCI/CDなどが幻滅期に、インダストリクラウドやインフラ自動化は過度な期待。「日本におけるクラウド・プラットフォームのハイプ・サイクル」2024年版発表 調査会社のガートナージャパンは、「日本におけるクラウド・プラットフォームのハイプ・サイクル：2024年」を発表しました。 ハイプサイクルとは ガートナーのハイプサイクルは、技術の登場から安定までを5つのステージに分けて説明したものです。5つのステージは、「黎明期」から始まり、「『過度な期待』のピーク期」「幻滅期」「啓発期」「生産性の安定期」まで。この途中で消えていく技術もあります。 同社はグローバルだけでなく国別などさまざまな切り口でハイプサイクルを発表しています。今回発表されたのは日本のクラウドプラットフォームにおけるハイプサイクルです。横幅の関係上、図を2つに分割しました。まずは前半部分。 黎明期にはFi
GitHub Actions の実践的なノウハウが凝縮されている素晴らしい一冊「GitHub CI/CD 実践ガイド」を読んだ - kakakakakku blog
GitHub Actions の実践的なノウハウが凝縮されている一冊「GitHub CI/CD 実践ガイド」を読んだ📕 本書ではソフトウェア開発ライフサイクルから GitHub Actions 基礎トピック・GitHub Actions 実践トピックが紹介されていて，さらに GitHub Actions を活用して実現するリリース自動化・パッケージ管理・セキュリティのシフトレフトまでもカバーされている❗️素晴らしい👏 GitHub Actions をなんとなーく使っていたり，いつも既存のワークフローをコピーしていたりする人は必読かなと ＼( 'ω')／ また著者の経験に基づくベストプラクティス（こうすると良いよ〜的な）が散りばめられているのも現場目線で読めて良かった❗️ GitHub CI/CD実践ガイド――持続可能なソフトウェア開発を支えるGitHub Actionsの設計と運用 エ
Devinとは、ソフトウェア開発におけるタスクを自動化・効率化してくれるAIプラットフォームです。2024年12月に正式リリースされました。 私が所属しているUbieにも先日導入されました。様々な作業ができますが、あるリポジトリで不足しているテストを書いてもらったところ、その便利さに感動して椅子から転げ落ちました。 本記事では、Devinの実際の使い方と、利用する上でのポイントを紹介します。 1. テストの作成をSlackで依頼する Slackで「これこれのテストを書いてほしい」と依頼すると、Devinがテストコードを生成し、GitHubに新しいPRを作ってくれます。 依頼例は次のとおりです。 こんにちは、 @Devin 以下の仕事をして - ubie-inc/リポジトリ名 repo にアクセスして - （テスト対象のパス） のテストを書いて - 次のテストの書き方を参考にして - foo
頑張りすぎず、PlaywrightのCI実行時間を短縮した話 - カミナシ エンジニアブログ
カミナシのソフトウェアエンジニアisanaです。 カミナシレポートの開発に携わっています。 私たちのチームでは、Webアプリケーションの品質担保のため、Playwrightを用いたブラウザテストを実装し、GitHub Actionsで実行しています。しかし、このCIプロセスにおいていくつかの課題がありました。 他方、ソフトウェア開発においては日々寄せられるVoCに対応したり、新機能の開発を行うなかで、負債や課題を上手くハンドリングしていく必要があります。 本稿では、CIプロセスにおける課題をコスパよく解決するための改善策と、その過程で遭遇した「ハマったポイント」について、具体的な設定例を交えながらご紹介します。 PlaywrightやGitHub Actionsを利用している開発者の方々にとって、少しでも参考になれば幸いです。 前提となる環境 本稿で紹介する事例は、以下の環境を前提としてい
はじめに GitHub Script概要 セットアップ context の中身 eSquare Liveでの活用事例 発生した問題 タグの打ち間違い releaseブランチが複数存在する場合のデプロイ先選択の複雑化 解決策としてのGitHub Scriptの活用 機能1 vX.Y.Zのタグがmainブランチのコミットハッシュと一致することを確認する 機能2 releaseブランチは最新バージョンのみ自動で検証環境にデプロイする 完成版スクリプト まとめ はじめに こんにちは、enechainでeSquare Liveを開発しているエンジニアの古瀬(@tsuperis3112)です！ 今回は、マニュアル依存になりがちなデプロイフローの問題を actions/github-script で解消した方法についてお話します。 eSquare Liveの開発では、効率的かつ信頼性の高い開発フローを維
こんにちは。こんばんは。 開発生産性の可視化・分析をサポートする Findy Team+ 開発のフロントエンドリードをしている @shoota です。 ファインディのフロントエンドでは多くのプロダクトでNxを用いたモノレポを構築しています。 tech.findy.co.jp Findy Team+のフロントエンドもNxを採用し、各パッケージ間の依存関係の管理やライブラリのマイグレーションなどの恩恵を受けています。 なかでも強力なキャッシュ機構をベースとしたCIの高速化はなくてはならない存在となっています。 以下は、このブログの執筆時点での Findy Team+のフロントエンドリポジトリが実行するCIの統計情報です。 Team+ の CI実行 直近30日間でCIの実行回数は2500回、平均時間は7分です。 そしてNxの機能によって削減された実行時間はなんと167日分（約4000時間）にもな
そのAnsibleコード適用して大丈夫？安全性を高めるAnsible CI環境を紹介します。 - RAKUS Developers Blog | ラクス エンジニアブログ
インフラ開発部でテックリードを務めております上畑です。 みなさんはAnsibleコードを修正した後に そのAnsibleコードを本番環境へ適用する際、ドキドキしていませんでしょうか? 前回、Ansibleをバージョンアップする記事を執筆し、大量のコード修正が必要になりました。 この記事では、ラクスがどのようにしてAnsibleコードをドキドキせずに本番に適用しているか、その仕組みを紹介します。 目次 目次 1. はじめに 2. DockerによるAnsible自動実行CIシステム 3. その他、CI環境の工夫 3-1. 本番環境Dockerイメージの最新化 3-2. CI実行時のエラー調査 3-3. CI/CDの並列実行を実現するコード化 3-4. 定期Dockerイメージの構築 4. 最後に 1. はじめに 一般的に、Ansibleコードを修正してマージする際には、以下のような事前チェッ
CIの時間を(できるだけ楽して)半分にしてみた - Nealle Developer's Blog
こんにちは、ニーリーの佐古です。 現在開発速度や開発者体験の向上のため、取り組みの諸々を遂行しています。 開発者体験とCI 天井の雨漏りが4か月ほど止まらないので私の開発者体験は酷いことになっています。 さて、皆さんCIの待ち時間はお好きですか？私は大嫌いです。 弊社バックエンドリポジトリのPR時CIはプロダクトの成長に合わせて実行時間が順調に伸びており、 開発速度と開発者体験の双方に悪影響をもたらしていました。 実は別チームで改善のための試みがなされたことはあったのですが、 そこで行き当たった問題をある程度解決してどうにかエピソードになる程度の成果を得られたので 簡単に記しておこうと思います。 前提 プロダクトはDjangoで、リポジトリはGitHubで管理されています。 AS-WAS ついこないだまでのPR時CI。 こちらがもともとのGitHub CIのグラフです。 正直経験上そこまで
GitHub Actionsで実行されるCIのキャッシュが初回実行だけ効かない問題を紐解く - Nealle Developer's Blog
背景と悩み SREチームの大木(@2357gi)です。いよいよ暖かくなってきましたね。春スキーの季節です。 チーム開発においてCIを如何に高速化するかという話は日夜行われていると思います。 弊社でも同様のことが行われており、その中でパッケージ管理ツールによるライブラリのキャッシングなどの高速化も実施しています。 しかし、キャッシュを指定しているはずなのに、「PRを作成して最初に走るCIではキャッシュがまったく効いていない」 というケースが存在しました。 お使いのGitHub Actions Workflow によっては実は同じ症状の方もいると思うので、ご参考になれば幸いです。 GitHub Actionsのキャッシュ仕様のおさらい GitHub Actionsのキャッシュはブランチごとに分けて生成されます。 もう少しいうと、キャッシュは「 ワークフローが実行されるブランチ」に紐づいて生成さ
2024/9/17に「GitHub CI/CD実践ガイド~ Forkwell Library#67」というイベントで登壇しました。本記事ではその講演をダイジェストでお届けします。あわせて当日のFAQにも回答します。 発表資料 イベントでは拙著『GitHub CI/CD実践ガイド』のポイントを解説しました。 資料はSpeakerDeckへ公開済みです。またアーカイブ動画がYouTubeから視聴できます。 発表ダイジェスト それでは講演内容をかいつまんで説明しましょう。アジェンダは次のとおりです。 CI/CDとはなにか GitHub Actionsの基本機能と作法 持続可能性を高める習慣 意図的脅威に対する防衛術 おわりに なおFAQだけ読みたい場合は、こちらをクリックすると飛べます。 1. CI/CDとはなにか 我々ソフトウェアエンジニアの仕事は「ソフトウェアをとおして、ユーザーに価値を届け
こんにちは！Findy Team+開発チームでEMをしているhamです。 Findy Team+のバックエンドはRuby on Railsで開発しており、Rubyの静的解析ツールとして広く知られているRubocopをTeam+の開発でも積極的に活用しています。 ファインディでは「爆速開発」を掲げており、開発速度に直結するCI（継続的インテグレーション）の実行時間を非常に重視しています。具体的には、CIの実行時間は遅くとも10分以内、理想としては5分以内に完了することを目標にしています。 CIの実行時間短縮に向けた取り組みについては、以前公開した次の記事で詳しくご紹介していますので、ぜひご覧ください。 tech.findy.co.jp 今回、バックエンドのCIの実行時間を見直したところ、Rubocopの実行時間が5分以上かかっていることに気づきました。これは改善の余地があると感じ、実行時間短
社内の9個のリポジトリの CI/CD を CircleCI から GitHub Actions に移行した際に考えたこと - Classi開発者ブログ
はじめに こんにちは、エンジニアの id:kiryuanzu です！今回はチームで管理するRailsリポジトリ9個の CI/CD を CircleCI から GitHub Actions に移行した際の話を共有します。 概要 Classi では全社的な方針により、メインで使う CI/CDプラットフォームを CircleCI から GitHub Actions に移行することにしました。 主な理由としては、複数の CI/CD サービスを並行して利用し続けるのは運用管理・コスト管理で負担があったこと、社内の知見交換で片方に寄せた方が良いと判断したためです。 筆者が所属するチームでは当時9個のリポジトリの運用を行っていました。それらのリポジトリの CI/CD を全て置き換えることになったため、期日までに全て移行できるように中期的な計画を立てて進めました。 今回の記事では、移行の際にまず取り組んだ
CI/CD Observability with OpenTelemetry - A Step by Step Guide In the fast-paced world of CI/CD, understanding the performance and behaviour of your pipelines is crucial. GitHub Actions has become a popular choice for automating builds and deployments, but anyone who's debugged a flaky workflow or long-running job knows how challenging it can be to get visibility into what's happening under the hoo
CI高速化戦略 ~ in Package By Feature ~ - バイセル Tech Blog
はじめに こちらはバイセルテクノロジーズのアドベントカレンダー2024の21日目の記事です。前日の記事は遠藤さんの「ジョブエクスプローラでBigQueryのボトルネックをリサーチする」でした。 こんにちは！私はテクノロジー戦略本部に所属し、2024年に新卒として入社した高橋です。 2023年の10月から内定者インターンとしての経験を積み、現在は開発3部のCRMチームでフロントエンドエンジニア（以下、FEエンジニア）として働いています。 この度、チーム内で継続的インテグレーション（以下、CI）の速度改善に取り組む機会があり、その内容を共有したく、この記事を執筆することにしました。 少しでもCIの速度にお悩みのFEエンジニアの方々の参考になれば幸いです。 はじめに 概要 前提 改善前のCI 構成 実行結果 検証 検証結果 現在 まとめ 概要 私たちのプロダクトは、開発当初から費用対効果を考慮し
フレーキーテストをCIで検知・アラートさせる仕組みを作った話（JUnit, Vitest） - Sansan Tech Blog
明けましておめでとうございます。 2024年は皆さんにとってどんな年だったでしょうか。 私たちSansanでは、本社移転により業務環境が大きく変わり、特に印象的な年になりました。 2025年も、より素晴らしい年になるように頑張りたいですね。 こんにちは。技術本部 Contract One Dev の川崎です。 現場の習慣を変える、契約データベース「Contract One」の開発業務を担当しています。 フレーキーテストをご存知でしょうか。 JetBrains社の記事にフレーキーなテストとは以下と定義すると記載があります。 *1Flaky なテストは、コードまたはテストそのものに変更がないにもかかわらず、合格と不合格の両方を返すテストであると定義されています。 つまりざっくり言うと、実行の度に成功したり失敗したりするテストのことを指してるわけですね。 Contract Oneにおいてもテスト
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
書籍『GitHub CI/CD実践ガイド』を読みやすくする技術
Devin AIにテストを丸ごと書かせてCIがパスするまで作業してもらう方法
CI/CD革新 GitHub Script活用術 - enechain Tech Blog
60万行を超えるフロントエンドのリアーキテクチャとCI戦略 - Findy Tech Blog
「GitHub CI/CD実践ガイド」イベント基調講演ダイジェスト＋FAQ #Forkwell_Library
CIで5分以上かかっていたRubocopを1分未満に短縮！ - Findy Tech Blog
CI/CD Observability with OpenTelemetry - A Step by Step Guide
【海外記事紹介】多くの企業がインフラストラクチャ・アズ・コードに苦戦している理由、そして「インフラストラクチャ・フロム・コード」が注目される理由
