リリース頻度を毎週から毎日にしてみた - NTT Communications 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 ↑のリ
CIによる機械的なコードレビューを可能にするDangerを使ってみた - Qiita
TL;DR この記事はgithub上でのコードレビューに役立つdanger(-js)というツールの紹介です。dangerのセットアップから簡単なレビュールールを記述するところまでのチュートリアルです。 dangerはプルリクエストをトリガとしCI上で実行され、チームメンバがコードレビューを始まる前に、機械的にレビューできる様々な項目をCIがレビューしてくれるツールです。レポジトリは以下です。 オリジナルのdangerはrubyで開発されていますが今回はjavascript版のdangerを紹介します。javascript版はNode.jsで動作します。 DangerによるPull Requestの機械的レビュー Pull Requestの機械的レビューと言われてもなかなかピンとこないかもしれません。例えば ブランチ名やブランチの向き先をチェックする 「向き先間違えてるよー 」とか Pull
CircleCI で yarn install が失敗したので対策を共有 - Qiita
環境 CircleCI 1.0 yarn v0.21.3 手順通りに circle.yml を書いてみたところ 公式ドキュメント yarn インストール失敗 そう簡単に行くことなく、yarn インストールが失敗。 $ yarn yarn install v0.21.3 [1/4] Resolving packages... ⠁ [2/4] Fetching packages... error laravel-mix@0.12.1: The engine "node" is incompatible with this module. Expected version ">=6.0.0". error Found incompatible module info Visit https://yarnpkg.com/en/docs/cli/install for documentation a
【Jenkinsを使った自動テスト環境を作る】Dockerコンテナを使って自動ビルドを実行する | OSDN Magazine
継続的インテグレーション（CI）ツールとして有名なJenkinsは、ソフトウェア開発におけるテストやビルドと言った作業を自動化するツールだ。後編となる今回は、Dockerを使ってコンテナ内に構築したビルド環境をJenkinsから利用する例を紹介する。 Jenkinsの「マスター/スレーブ」機能 前回記事では、Jenkinsをインストールしたサーバー内でソフトウェアのビルドやテストを行うことを前提に環境を構築していった。Jenkinsをインストールしたサーバーと、対象とするソフトウェアのビルド/実行環境が同じで構わなければこれで問題はないが、たとえばそれぞれビルド/実行環境が異なる複数のソフトウェアをJenkinsで管理したい場合、このやり方では複数台のサーバーを用意しなければならない。 Jenkinsではこういった問題を解決するため、Jenkinsがインストールされたサーバーとは異なる
Heroku CIが正式にリリース：簡単に、すぐに使い始められるCI
本ブログは、米国で発表した Heroku CI Is Now Generally Available: Fast, Low Setup CI That’s Easy to Use の翻訳版です。 セールスフォース・ドットコムではHeroku CIを正式リリースし、提供を開始します。これはユニットテストとブラウザテスト向けのすぐに利用可能なテスト実行環境であり、Heroku Pipelinesと密接に統合されています。 最近の傾向として、多くの開発者がソフトウェアの品質を担保しながら素早く機能を最適にリリースするために、継続的インテグレーション（以下、CI）をベストプラクティスとしています。またそれは継続的デリバリー（以下、CD）を実現するために必須となっています。ビルド、デプロイメント、そしてCDの実現のために、Heroku CIは利便性、開発体験、そしてCIの機能を飛躍的に向上します。開
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Jenkins X - Cloud Native CI/CD Built On Kubernetes
