npm provenance general availability
September 26, 2023 npm provenance is now generally available. npm packages built on a supported cloud CI/CD system can publish with provenance. Today this includes GitHub Actions and GitLab CI/CD. Publishing with provenance verifiably links the package back to its source repository and build instructions. Provenance is restricted to public packages and public source repositories only. npm will che
スペシャルセッション「その ＼よーいドン！／ デプロイが、あなたのサービスの信頼性を損ねている」ーAWS DevAx::connect シーズン 3 「rethink CI/CD」（前編 第 4 回)
スペシャルセッション 「その ＼よーいドン！／ デプロイが、あなたのサービスの信頼性を損ねている」 ◆登壇者 講師：Tori Hara (@toricls) 氏 (CTO, Kaminashi) 進行：杉本 晋吾（アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト） パネリスト：福井 厚（アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト）/ 下川 賢介 (アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト）/ 野村 侑志 (アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト）/ 林 政利 (アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト）/ タメルラン トルガエフ (アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト） ◆ セッション概要： 本セッシ
GitHub ActionsのSelf-hosted RunnerをM1 Macで構築して、iOSのCI/CDが快適になった話
こんにちは！テラーノベルでiOS/Android/Webとフロントエンド周りを担当している @kazutoyoです！ テラーノベルのCI/CDは、Bitriseを利用していました。（旧プランでTeamsプラン移行前のもの） BitriseはモバイルにフォーカスされたCI/CDサービスで、かんたんにモバイルでのCI/CDパイプラインを構築できる素晴らしいサービスです。 ただし、テラーノベルのアプリ開発において、以下のような問題点がありました。 テラーノベルでのBitriseを利用する問題点1: マシンタイプが現在では古い こちらは旧プランを利用していたためGen２マシンを利用できなかったからなのですが、当時のEliteプランでもMac mini 2018年モデルでした。 Model Identifier: Macmini6,2 machdep.cpu.brand: 0 machdep.cpu
開発環境のセキュリティおよびCI/CDパイプラインのセキュア化
English Version is here --- 実施: セキュリティ・キャンプ全国大会2022 発表者: Hiroki SUEZAWA (@rung) 演習レポジトリ: https://github.com/rung/training-devenv-security スライド内容 : この10年で、ソフトウェアを開発する環境は大きく変化してきました。DevOpsカルチャーの浸透や、Cloud基盤の利用の増加を受け、ソフトウェアはCI/CDパイプラインを通じてデプロイされるようになりました。また、開発はオフィス内だけでなく、会社の外でも実施されるようになりました。 本スライドでは、現代のプロダクション環境を攻撃および保護するためにはどのような手法を用いることができるのか、主にマルウェアなどを用いたクライアントサイドへの攻撃や、サプライチェーン攻撃の視点から、総合的に攻撃手法および対策
The Ubuntu 18.04 Actions runner image will begin deprecation on 2022/08/08 and will be fully unsupported by 2023/04/03 · Issue #6002 · actions/runner-images
Breaking changes We have started the deprecation process for Ubuntu 18.04. While the image is being deprecated, You may experience longer queue times during peak usage hours. Deprecation will begin on 2022/08/08 and the image will be fully unsupported by 2023/04/03 To raise awareness of the upcoming removal, we will temporarily fail jobs using Ubuntu 18.04. Builds that are scheduled to run during
リリースノート管理術
みなさま、OSSの変更履歴、要するにCHANGELOGやリリースノートはどのように管理しておられるでしょうか。自分はというと、抱えるリポジトリも数百個に増えてきて、まあ要するに細かく管理するのがだるく、最近は変更履歴の管理方法も変わってきました。 CHANGELOGからGitHub Releasesへ 昔は、おおよそKeep a changelogの方式に準拠したCHANGELOG.mdを書いていました。semantic versioningでバージョン管理をしながら、個々のバージョンごとに次のセクションを設けて変更内容を説明するような感じです。 Added Changed Deprecated Fixed Removed Security 今は、新規につくるリポジトリではCHANGELOG.mdは用意せず、GitHub ReleasesにKeep a changelogに似た形式で変更内
同じビルドやテストを何度も実行しない方法 - コンポツさん
GitHub Actions で同じビルドやテストを何度も実行しない方法を紹介します。 ホストランナーを ubuntu-linux にした場合、実行する必要のないジョブは 10 秒程度でスキップ可能です。 注意 この記事は自作の OSS ツール sver および私が現在所属するサイボウス社の グローバル向けAWS版kintone開発チーム の宣伝が含まれます。 Summary ビルドやテストといった CI のジョブに再現性がある場合は複数回実行しても意味がない ジョブが依存する環境やソースコードを元にハッシュ値を計算することで同等なジョブに一意なラベルをつけられる ジョブ実行後に実行済みラベルを artifact として保存しておくことで後続の同等なジョブをスキップできる 効果 最初に効果を示します。 sver というプロジェクトのジョブの実行結果です。 これは通常時のジョブの実行時間です
複数ブランチ運用は『単一のコードベース』と言えるのか | CI/CD Conference 2021 by CloudNative Days
architect - システム設計 developer - システム開発 app-developer - アプリケーション開発 operator/sys-admin - 運用管理/システム管理 かの有名な The Twelve-Factor App は、その「コードベース」の章で「一つのコードベースと複数のデプロイ」が重要であると説いています。[1] 周りを見渡してみましょう。develop ブランチ release ブランチ main ブランチ... おやおや。複数のコードベースから複数のデプロイが生まれているではありませんか。 The Twelve-Factor App はもう古い、そんなのできていて当たり前などという言葉が聞こえてくることもある昨今ですが、そもそも当たり前すぎるセオリーすら満たせていない現場はあまりにも多そうです。 The Twelve-Factor App が間違
Playwright & Vite ではじめる脱レガシー向け軽量 Visual Regression Test - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは！フロントエンドエキスパートチームの @mugi_uno です。 みなさんは Visual Regression Test は普段活用していますか？ 昨今では事例もよく耳にするようになった印象です。一度使って手放せなくなった方もいるのではないでしょうか。 今回の記事では、通常のプロダクト新規開発とは異なる “脱レガシー” の文脈で Playwright を用いた簡易的な Visual Regression Test を試してみたので、導入に至る経緯と、どのように実施しているかを紹介します。 フロントエンドリアーキテクチャとサイレントリリース 現在サイボウズでは kintone のフロントエンドリアーキテクチャプロジェクトと称して、Closure Tools から React への脱レガシー作業が進行中です。プロジェクトの詳細については @koba04 が書いた次の記事をご覧くださ
AWS AmplifyでのフルスタックアプリケーションのCI/CDパイプラインの構築 | Amazon Web Services
Amazon Web Services ブログ AWS AmplifyでのフルスタックアプリケーションのCI/CDパイプラインの構築 この記事は、Complete guide to full-stack CI/CD workflows with AWS Amplifyを翻訳したものです。 AWS Amplify は、1) 条件付きバックエンドデプロイ、2) ビルド時のaws-exports.js の自動生成、3) 異なるAmplify アプリケーション間でのバックエンドの共有といった３つの新しい機能をAmplify のCI/CD ワークフローに追加しました。これらの機能を使用することで、より柔軟にフルスタックアプリケーションをデプロイすることが可能です。 AWS Amplify は、フルマネージドな CI/CD およびホスティングサービスを提供し、開発者は Git リポジトリを接続するだけ
メルカリShops の CI/CD と Pull Request 環境 | メルカリエンジニアリング
こんにちは！ソウゾウの Software Engineer の @dragon3 です。 連載：「メルカリShops」プレオープンまでの開発の裏側の８日目を担当させていただきます。 この記事では、メルカリShops 開発において、日々バリバリに利用されている CI/CD 環境と Pull Request 毎のデプロイ環境について紹介します。 CI/CD 環境 メルカリShops では、CI/CD （テスト・ビルド・デプロイ）やその他自動化のために GitHub Actions を使っており、ほとんどのワークフロー・ジョブを Self-hosted runners で実行しています。 Self-hosted runners は、専用の VPC ネットワーク 内の GCE インスタンス上で動かしており、Managed Instance Group 等を使い、そのプロビジョニングや起動・停止等は
published: trueを自動化することで Zenn への記事投稿フローを改善した話
僕は Zenn の記事を GitHub で管理しています。今回、記事のメタデータを更新する GitHub Action を作ってデプロイフローを改善したのでそれを紹介します。 TL;DR 対象 Zenn の記事を GitHub で管理している 記事の公開前に Zenn 上で記事の確認をしている 内容 Zenn のメタデータを自動更新してプルリクを作ってくれる GitHub Action を作ったよ 手動で published: true をする手間が省けるよ 背景 Zenn の記事は GitHub で管理できます。連携設定をしたのち、main ブランチ[1]の articles 下にメタデータの埋め込まれた Markdown ファイルを置くことで Zenn にその記事がデプロイされます。記事を GitHub で管理したいと思っている自分にとってとてもありがたい機能です。 Zenn 記事のマ
インフラのリリース自動化戦略とその行き着く先 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、@ueokandeです。 本番リリースってドキドキしますよね。 本日はkintone.comのリリース自動化と、その戦略についてお話します。 kintone.comのCI/CDパイプライン kintone.comのインフラ構成はモノレポで管理しており、AWSの構成や、Kubernetes上にデプロイするサービスなどが1つのレポジトリに存在します。 現在のkintone.comは、開発環境、ステージング環境、本番環境の3つがあります。 適用タイミングをずらすことによる環境間の乖離を防ぐため、各リリースはすべての環境に適用することとしました。 開発環境でしばらく寝かせたい変更は、機能フラグやカナリアによって切り替えます。 CI/CDパイプラインは以下のようになっています。 それぞれの環境に順に適用し、本番環境適用後にテストが通れば無事リリース完了です。 kintone.comのCI
GitHub Actions でテストを並列に実行して高速化する (parallelism)
bin/rspec --format progress --format RspecJunitFormatter --out report/rspec-${{ matrix.node_index }}.xml $(./split-test --junit-xml-report-dir report-tmp --node-index ${{ matrix.node_index }} --node-total 2 --tests-glob 'spec/**/*_spec.rb' --debug) [2021-01-08T07:12:09Z WARN split_test] Timing data not found: /home/runner/work/split-test-example/split-test-example/spec/1_spec.rb ... [2021-01-08T07
フィーチャーフラグ入門 | CloudBees|テクマトリックス
タイトルどおり、このガイドではフィーチャーフラグについて説明したいと思います。 フィーチャーフラグとは何なのか？ どのように使えばよいのか？ どのように始めればよいのか？ これらのトピックをすべてカバーしたうえで、ほかの話題にもいろいろ触れていきます。 フィーチャーフラグが興味深いのは、簡単そうでいて奥が深いという点です。 「フィーチャーフラグとは何なのか」という質問に対しては、2つ3つのセンテンスで答えることも、本をまるまる一冊書くこともできます。 コンテキストによって、どちらの答えも適切でしょう。 ですから、基礎を全部カバーできるよう、できるだけ簡単なところから始め、だんだんに詳細に入っていくことにしましょう。 フィーチャーフラグとは何か？必要最小限の定義 ソフトウェアでフラグと言えば、「バイナリ値の格納に使用される1またはそれ以上のビット」です。つまり、trueまたはf
巨大なアプリの開発を支えるフラグ管理術 - DroidKaigi 2019
DAY.01 (Feb 7th, 2019)Hall AHall BRoom 1Room 2Room 3Room 4Room 5Room 6Room 710:00
第3回 ブランチvs.フラグ | gihyo.jp
とっておきの変更 ソフトウェアをいつでもリリースできるようにしろと求める継続的デリバリの広まりにより、毎日のようにソフトウェアがリリースされるようになりました。早いうちからコードを野にさらせば、隠れた問題を前もって見つけることができるからです。 短いリリース間隔に身を置くと気づくことがあります。「リリースできること」と「リリースしたいこと」は、必ずしも一致しないのです。たとえば大規模なビジュアルデザインの変更やとっておきの新機能を想像してみましょう。こうした粒度の大きい変更は、たとえ動作する、つまりリリース可能な状態でも、そのまま衆目にさらしたいとは限りません。期待を裏切らない形でお披露目したい、とっておきの変更があります。息を飲む新しい体験がもたらすユーザの驚きや喜びも、ソフトウェアにとっては大切な財産だからです。 とっておきの変更を仕上げるには時間がかかります。一方で、その仕上げが終
Feature Management | Manage feature rollouts and effectiveness
Feature Management Harnessing the Speed and Safety of Software Delivery With Feature ManagementExplore feature management, a software development practice that uses feature flags for controlled functionality deployment. This approach enables live testing, risk mitigation, and efficient software delivery. Feature management is a software development practice that allows teams to control the visibil
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CI/CD Supply Chain Attacks for Data Exfiltration or Cloud Account Takeover
GitHub - danger/danger-js: ⚠️ Stop saying "you forgot to …" in code review
