並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 97件

新着順 人気順

ciの検索結果1 - 40 件 / 97件

  • 結局 Git のブランチ戦略ってどうすればいいの? - Qiita

    1つのIssueが大きくなると1 Pull Requestで大量の差分が発生します。 そうなるとレビュワーに負担がかかり、コンフリクトの可能性も高まり、コードレビューを効率よく進めることができません。 このINVEST原則を守ることでチームはより効果的に作業を進め、柔軟に対応して開発を進めることができます。 Git Flow Git Flowは5種類(main, hotfix, release, develop, feature)のブランチを運用するブランチ戦略です。 2010年に提唱された有名なブランチ戦略です。 オンラインサービスのように継続的デリバリーするコードを想定して作られた戦略ではないです。 main ブランチ 常にリリースできる状態を保つ hotfix, develop へ切り出す このブランチへの直pushはNG hotfix ブランチ バグ修正など緊急時に対応するためのブ

      結局 Git のブランチ戦略ってどうすればいいの? - Qiita
    • エンジニアとして働く中で気づけた大切だと思うこと - Qiita

      はじめに 自分がIT業界に携わって5年ほどが経過しました。 この5年間、SIerからフリーランスエンジニアに転身し、様々なプロジェクトに参加する中で、数々の失敗と成功を経験しました。特に心構えやマインドの部分で多くを学ぶことができました。 未熟だった自分を振り返って、今では改善できた点が多くあると思います。同じ失敗を繰り返さないように、自分の経験が少しでも役立てば幸いです。 また、気付きを与えてくれた方々にこの場を借りて感謝します。 感謝を忘れない 進捗報告やコードレビュー、質問対応など、感謝の気持ちを忘れないようにしています。感謝は、コミュニケーションを円滑にし、相手の意欲を引き出す力があると思います。 たとえば、昔の自分はバグ報告を受けるとろくに文章も読まず「影響範囲は? 再現する条件は? 原因は? 解決策は?」などと質問攻めにしてしまっていました。 報告しただけなのに色んなことを聞か

        エンジニアとして働く中で気づけた大切だと思うこと - Qiita
      • 『SUUMO』を止めるな。大規模横断バッチがEOSLを迎える「2027年問題」にどう立ち向かったか - はてなニュース

        あらゆるソフトウェアに存在する「サポート期限(End Of Service Life、EOSL)」。EOSLを迎えたソフトウェアにはパッチなども提供されなくなるため、安定した運用が困難になります。メーカーからのアナウンスがあれば、より新しいソフトウェアへの移行計画を作成し、これまで動作してきたアプリケーションプログラムの稼働に影響がないかを確認し、場合によっては改修を加えるといった一連の対応が求められますが、それには多くの労力が必要です。 1つのシステムですらこれほど大変なEOSL対応ですが、賃貸を取り扱う事業、新築マンションを取り扱う事業など、複数の事業領域で構成されている『SUUMO』では、仮想化ソフトウェアのEOSLを機に「複数の異なる領域で横断的に利用される、12万以上のジョブが動作する横断バッチの移行プロジェクト」を実行、無事完遂しました。 事業に不可欠でありながら、新規サービス

          『SUUMO』を止めるな。大規模横断バッチがEOSLを迎える「2027年問題」にどう立ち向かったか - はてなニュース
        • ボタンをaタグで作るな高校校歌 - 弁護士ドットコム株式会社 Creators’ blog

          まずはこちらをお聞きください。 技術的解説: ボタンを a 要素で作るな a 要素は URL などへのリンクをつくるためのもので、button 要素はなんらかの処理を起動するボタンをつくるためのものです。 配置されるものがリンクなら a 要素で実装し、ボタンなら button 要素で実装すべきです。 これに違反すると、意図しない動作や、アクセシビリティ上の問題が発生します。 これは MDN でも詳しく説明されています。 onclick イベント -- \<a>: アンカー要素 - HTML: ハイパーテキストマークアップ言語 | MDN よく見られる誤った使い方として、擬似的なボタンを作成するためにアンカー要素を使用し、href を # または javascript:void(0) に設定してページの再読み込みを防ぎ、click を待ち受けするようにするというものがあります。 これらの偽の

            ボタンをaタグで作るな高校校歌 - 弁護士ドットコム株式会社 Creators’ blog
          • KPIのモニタリング自動化と運用体制の整備 - ZOZO TECH BLOG

            はじめに こんにちは。データシステム部/推薦基盤ブロックの佐藤 (@rayuron) です。私たちはZOZOTOWNのパーソナライズを実現する推薦システムを開発・運用しています。推薦システムごとにKPIを策定していますが、データの欠損やリリース時の不具合によってKPIが意図しない値を取ることがあるため定常的に確認する必要があり、これをKPIのモニタリングと呼んでいます。 先日、推薦システムの実績をLookerでモニタリングするというテックブログで推薦システムのKPIをモニタリングする方法を紹介しましたが、運用していく中でいくつかの課題が見えてきました。本記事では、より効率的かつ効果的なKPIのモニタリングを実現するための取り組みについて詳しくご紹介します。 はじめに 改善の背景と課題 背景 課題 トレンドを考慮した異常検知が不可能 モニタリングの設定が面倒 アラート対応フローが不明確 サマ

              KPIのモニタリング自動化と運用体制の整備 - ZOZO TECH BLOG
            • 日本ではKubernetesやCI/CDなどが幻滅期に、インダストリクラウドやインフラ自動化は過度な期待。「日本におけるクラウド・プラットフォームのハイプ・サイクル」2024年版発表

              日本ではKubernetesやCI/CDなどが幻滅期に、インダストリクラウドやインフラ自動化は過度な期待。「日本におけるクラウド・プラットフォームのハイプ・サイクル」2024年版発表 調査会社のガートナージャパンは、「日本におけるクラウド・プラットフォームのハイプ・サイクル:2024年」を発表しました。 ハイプサイクルとは ガートナーのハイプサイクルは、技術の登場から安定までを5つのステージに分けて説明したものです。5つのステージは、「黎明期」から始まり、「『過度な期待』のピーク期」「幻滅期」「啓発期」「生産性の安定期」まで。この途中で消えていく技術もあります。 同社はグローバルだけでなく国別などさまざまな切り口でハイプサイクルを発表しています。今回発表されたのは日本のクラウドプラットフォームにおけるハイプサイクルです。横幅の関係上、図を2つに分割しました。まずは前半部分。 黎明期にはFi

                日本ではKubernetesやCI/CDなどが幻滅期に、インダストリクラウドやインフラ自動化は過度な期待。「日本におけるクラウド・プラットフォームのハイプ・サイクル」2024年版発表
              • やんないほうがいいかも、GitHub Actions の setup-xxx での依存キャッシュ保存 - 誰かの役に立てばいいブログ

                GitHub Actions で CI している皆様、こんにちは。 GitHub Actions 便利ですよね。使わない日がないというくらい毎日お世話になっています。 さて、CI といえば良く問題になるのが実行時間。 長い待ち時間は開発効率を下げますし、プライベートリポジトリだと Runner の費用も嵩んでしまいます。 時間を短縮する方法は色々ありますが、一手目によく行われるのが依存パッケージのキャッシュじゃないかなと思います。 例えば Go で開発していると、依存パッケージは ~/go/pkg/mod にダウンロードして保存されます。 これを CI 実行のたびにダウンロードしてコンパイルするのは時間とお金の無駄というものです。 幸い、GitHub Actions には CI の実行間でこういった依存パッケージを保存して再利用できるキャッシュ機能があります。 詳しくは以下のドキュメントを

                  やんないほうがいいかも、GitHub Actions の setup-xxx での依存キャッシュ保存 - 誰かの役に立てばいいブログ
                • 39社のデータアーキテクチャ特集 - ツールの技術選定のポイントと活用術 - Findy Tools

                  8つのデータ系ツール「BigQuery」「Databricks」「dbt」「Fivetran」「Lightdash」「Looker」「Snowflake」「TROCCOⓇ」に39社からご寄稿頂いたレビューから、各社のデータアーキテクチャをまとめた記事です。各社の技術選定の背景や工夫などの知見を得ていただく場となれば幸いです。 ※ツール名・ご寄稿企業名共にアルファベット順で掲載しております BigQueryBigQuery は、Google Cloud の費用対効果に優れたフルマネージド型の分析データ ウェアハウスです。ペタバイト規模に対応しており、膨大な量のデータに対してほぼリアルタイムで分析を行うことができます。 ▼BigQueryとは?機能や特徴・製品の概要まとめページはこちら https://findy-tools.io/products/bigquery/49 ▼Findy Too

                    39社のデータアーキテクチャ特集 - ツールの技術選定のポイントと活用術 - Findy Tools
                  • Findyの爆速開発を支えるPull requestの粒度 - Findy Tech Blog

                    こんにちは。 Findy で Tech Lead をやらせてもらってる戸田です。 既に皆さんも御存知かと思いますが、弊社では開発生産性の向上に対して非常に力を入れています。 以前公開した↓の記事で、弊社の高い開発生産性を支えている取り組み、技術についてお話させていただきました。 tech.findy.co.jp ありがたいことに、この記事を多くの方に読んでいただき反響をいただいております。 そこで今回は、↑の記事でも紹介されている「Pull requestの粒度」について更に深堀りしてお話しようと思います。 Pull requestの粒度は、弊社にJOINしたら最初に必ず覚えてもらう最重要テクニックの1つです。 それでは見ていきましょう! 大きなPull request 適切な粒度とは 適切な粒度を維持するために タスク分解 迷ったら小さく レビューを最優先にする CI高速化 featur

                      Findyの爆速開発を支えるPull requestの粒度 - Findy Tech Blog
                    • テストサイズで再考する「テストピラミッド」 Googleが提唱する効率的な自動テスト戦略

                      ソフトウェアエンジニアリングの第一人者・和田卓人氏が、効果的な自動テスト戦略について解説しました。ユニットテストの定義の曖昧さから生じる問題点を指摘し、Googleが提唱する「テストサイズ」の概念を紹介。さらに、テストピラミッドの再解釈と最適化について論じ、テストサイズに基づくアプローチがビルドパイプラインの効率化にもたらす利点について解説しました。前回の記事はこちら。 短時間でのテスト実行 和田卓人氏:ということで、じゃあ、次にいきます。短い時間で到達するというアジェンダ、3ポチ目ですね。 「信頼性の高い」、これはテストの結果に嘘がないという話でした。「実行結果」、これは信号として、また問題箇所の絞り込みとしてのテストの実行結果にこだわろうという話でした。そういったテストを、短い時間で到達する、信頼性の高い結果に短い時間で到達する状態を保つ。短い時間で。 ユニットテストの定義の曖昧さ と

                        テストサイズで再考する「テストピラミッド」 Googleが提唱する効率的な自動テスト戦略
                      • 【フルスタックエンジニアへの道!】ReactとTypeScriptの修行をした話 - Findy Tech Blog

                        こんにちは、ファインディでFindy Team+(以下Team+)を開発しているEND(@aiandrox)です。 普段はバックエンドの開発をメインで担当しているのですが、3ヶ月間フロントエンドの開発に挑戦する機会がありました。短い期間でしたが、フロントエンドテックリードから直接指導してもらいながら実装をすることで、フロントエンドの開発を一人でできるくらいに慣れることができました。 今回は、その経験と学びについて書いていきます。 フロントエンドに挑戦する前の自分について フロントエンドに挑戦することになった経緯 フロントエンドを学ぶ上で助けられたこと フロントエンドのノウハウが溜まった記事の充実 開発ツールが揃っている テックリードとマンツーマンでタスクをやっていく react.devの輪読会 つまづいた点 タスク粒度を適切に分割すること Team+のフロントエンドの責務の考え方 Type

                          【フルスタックエンジニアへの道!】ReactとTypeScriptの修行をした話 - Findy Tech Blog
                        • 持続可能なソフトウェア開発を支える『GitHub CI/CD実践ガイド』

                          書籍『GitHub CI/CD実践ガイド』はGitHub Actionsの基本構文からスタートし、テスト・静的解析・リリース・コンテナデプロイなどをハンズオン形式で学べる一冊です。Dependabot・OpenID Connect・継続的なセキュリティ改善・GitHub Appsについても解説し、実運用…

                            持続可能なソフトウェア開発を支える『GitHub CI/CD実践ガイド』
                          • Four Keysを活用してチームの開発生産性を改善した時のふりかえりの考え方と手法を紹介します - ZOZO TECH BLOG

                            はじめに こんにちは、データシステム部MLOpsブロックの薄田(@udus122)です。 この記事ではFour Keysなどの指標を活用して、定量的な根拠に基づきチームの開発生産性を改善する考え方とふりかえり手法を紹介します。 Four Keysとはデプロイ頻度、変更のリードタイム、変更障害率、平均修復時間の4つの指標からなるソフトウェアデリバリーや開発生産性の指標です。 Four Keysなど開発生産性の指標を計測し、定期的にふりかえっているけれど、なかなか具体的な改善につながらない。 そんな悩みはないでしょうか? 実際に私たちのチームで抱えていた開発生産性の改善に関する課題と解決策を紹介します。皆さんのチームで開発生産性を改善する際のご参考になれば幸いです。 目次 はじめに 目次 開発生産性の改善に取り組んだ背景 チームの改善に取り組む上での課題 Four Keysの考え方に対する理解

                              Four Keysを活用してチームの開発生産性を改善した時のふりかえりの考え方と手法を紹介します - ZOZO TECH BLOG
                            • ファインディでのGitHub Actions高速化の事例 - Findy Tech Blog

                              ファインディ株式会社でフロントエンドのリードをしております 新福(@puku0x)です。 弊社では、数年前に社内のCI環境をすべてGitHub Actionsに移行しました。 この記事では、弊社のGitHub Actions活用事例の内、CI高速化についてご紹介します。 なぜCI高速化に力を入れるのか CI高速化 キャッシュの活用 ジョブの並列化 Larger Runners まとめ なぜCI高速化に力を入れるのか 当ブログをはじめ弊社では、たびたびCI高速化の大切さについて言及しています。 Findyの爆速開発を支えるテクニック - Findy Tech Blog RailsのCIのテスト実行時間を 10分から5分に高速化した話 - Findy Tech Blog Findy転職フロントエンドの開発生産性を向上させるためにやったこと - Findy Tech Blog これはなぜでしょう

                                ファインディでのGitHub Actions高速化の事例 - Findy Tech Blog
                              • OSS開発に参加する方法 - 2024-09-18 - ククログ

                                こんにちは。7月にクリアコードに入社した藤田です。 クリアコードでは「フリーソフトウェアで稼ぐ」という理念をもとに、さまざまな活動がオープンになっており、 OSS開発もその一環です。 私が所属するチームは、Fluentdという拡張性の高いOSSのログ収集ソフトウェアを扱っています。 クリアコードに入社するとともに、新たなOSSに挑戦しております。 そこで、この記事では私なりのOSSに参加する方法についてご紹介したいと思います。 この内容に沿って作業されると、すぐにPull Requestを作成することができるかと思います。 それを足がかりにより大きな課題へ挑戦してみてください。 クリアコードでOSS開発 私が所属しているFluentdチームは、Fluentdの導入支援や運営サポートなどの エンタープライズサポートをベースに、Fluentdをオープンに開発しています。 我々の活動は http

                                  OSS開発に参加する方法 - 2024-09-18 - ククログ
                                • 高速な仮説検証ループで届けた新規プロダクトの成果を既存プロダクトにも反映するドリームチームの開発手法 ─ カケハシyabusameインタビュー - Agile Journey

                                  株式会社カケハシは「日本の医療体験を、しなやかに。」というミッションを掲げた、医療系のスタートアップです。現在は薬局向けのSaaSを主軸としたビジネスを行っており、多くのエンジニアがチームを組んで開発に取り組んでいます。その開発チームのひとつ「yabusame」は、特徴的なチーム編成もあって社内外で注目を集めています。 メンバーの椎葉光行(@bufferings)さん、小田中育生(@dora_e_m)さん、荻野淳也(@ogijun)さん、種岡篤志さん、平松拓(@hirataq__)さんは、それぞれが開発チームをリードできる高い技術力やマネジメント能力だけでなく、細やかな対人スキルや広い視座でメンバーの関係性を捉える能力を備えたシニアエンジニアでありながら、同じチームのメンバーとして開発に取り組んでいます。 日本の古式弓馬術である流鏑馬(やぶさめ)から「変化が速い中を駆け抜けて、的確にゴール

                                    高速な仮説検証ループで届けた新規プロダクトの成果を既存プロダクトにも反映するドリームチームの開発手法 ─ カケハシyabusameインタビュー - Agile Journey
                                  • AWS ECS で実現するBlue/Green Deployment:運用を見据えたCDK実装例 - Techtouch Developers Blog

                                    始めに 対象者 作成するアプリケーション構成 運用を見据えた構成とは 構成概要 各スタックの説明 ① SampleInfrastructureStack ② SampleContainerRepositoryStack ③ SampleTaskDefinitionStack ④ SampleServiceStack ⑤ SampleServicePreferenceStack ⑥ SamplePipelineStack 動作確認 正常にデプロイが完了する場合のCodeDeployの挙動 ロールバックが発生する場合のCodeDeployの動作 終わりに 始めに バックエンドの com です。 テックタッチでは Blue Green Deployment 構成の ECS クラスタを、AWS CDK によるコードで管理しながら本番運用で使っています。 ECS Blue Green Deploym

                                      AWS ECS で実現するBlue/Green Deployment:運用を見据えたCDK実装例 - Techtouch Developers Blog
                                    • 和田卓人氏が考える“自動テストの真の目的”とは?  コスト削減ではなく「変化に対応する力」を得るためのベストプラクティス

                                      ソフトウェアエンジニアリングの第一人者である和田卓人氏が、自動テストの本質と望ましい姿について語りました。コスト削減ではなく「変化に対応する力」を得るための自動テストの重要性や、信頼性の高い自動テストを実現するための具体的な方法論を解説。まずは、偽陽性や偽陰性の罠を避け、持続可能なソフトウェア開発を実現するための洞察に満ちた講演内容を紹介しました。全4回。 和田卓人氏自己紹介 和田卓人氏:よろしくお願いします。 (会場拍手) お招きいただきましてありがとうございます。「望ましい自動テストとは」というタイトルで、自動テストに関するお話をさせていただきたいと思います。和田卓人と申します。インターネット上ではだいたい「t-wada」さんと呼ばれていて、t-wadaアカウントが下にいろいろ並んでいるんですが、ソーシャルアカウントをいろいろやっていますという感じです。 本日の講演、私の講演はいつもス

                                        和田卓人氏が考える“自動テストの真の目的”とは?  コスト削減ではなく「変化に対応する力」を得るためのベストプラクティス
                                      • コードレビューの時に気にしている、べからずTierリスト

                                        こんにちは!アルダグラムのKANNAの開発お手伝いをさせて頂いているoubakiouです。 KANNAでは主にバックエンドにRails+graphql-rubyやKotlin+DGS、WebフロントエンドにTypeScriptとReactを採用していて、私が参加するチームでの仕事もそれらを触る事が多いのですが今回はそこでコードレビューをする際に気にしている「べからず」をティア別に見ていきましょう。 特に理由なくlintを無視してはいけない アルダグラムでは利用エディタの規定や制限はありませんが、Webフロントエンド開発で一番利用者が多いのはVSCodeでextensions.jsonにlint表示等のために必要な拡張プラグインリストが整備され半自動でインストールされるようになっています。VimなどVSCode以外のエディタを利用する場合には同等のリアルタイムlint表示ができるよう自主整備

                                          コードレビューの時に気にしている、べからずTierリスト
                                        • ローコード・ノーコードに潜むリスクを攻撃ツールで確かめてみた(インターンシップ体験記) - NTT Communications Engineers' Blog

                                          こんにちは、NTTドコモグループの現場受け入れ型インターンシップ2024に参加させていただきました、佐藤と鈴木です。 本記事では、現場受け入れ型インターンシップ「D1.攻撃者視点に立ち攻撃技術を開発するセキュリティエンジニア」での取り組み内容について紹介します。NTTドコモグループのセキュリティ業務、とりわけRedTeam PJに興味のある方への参考になれば幸いです。 目次 目次 RedTeam PJの紹介 参加に至った経緯 インターンシップ概要 ローコード・ノーコードとは 検証業務 Power Pwnの概要 PowerDump reconコマンド dumpコマンド 条件や制約の調査 dumpコマンドの制約 検証まとめ 感想 おわりに RedTeam PJの紹介 私たちは、NTTコミュニケーションズ イノベーションセンター テクノロジー部門 RedTeam PJのポストに参加しました。Re

                                            ローコード・ノーコードに潜むリスクを攻撃ツールで確かめてみた(インターンシップ体験記) - NTT Communications Engineers' Blog
                                          • TVerにバックエンドエンジニアとして中途入社した最初の3ヶ月 - TVer Tech Blog

                                            はじめまして。id:takanamitoです。 バックエンドエンジニアとしてTVerに入社して3ヶ月が経ちました。 TVerに入ってみて感じたこと、開発組織が何に取り組んでいるのか書いてみようと思います。 TVerのオンボーディング ドキュメントをたくさん書く文化を広める たくさん質問・相談する TVerが取り組んでいる開発とは この先やりたいこと TVerのオンボーディング TVerのバックエンドエンジニアは自分を含めて5名です。サービス規模に対してとても少なく感じるのではないでしょうか?自分も入社前の面談で聞いて驚きました。 バックエンドエンジニアは2チームに分かれており、プロダクトの機能開発をするStream Alignedチーム(SAチーム)、SAチームと連携し開発基盤を整えるEnablingチームがあります。 今はまだ人数が少ないですが、開発チームを大きくすべく採用活動中です。

                                              TVerにバックエンドエンジニアとして中途入社した最初の3ヶ月 - TVer Tech Blog
                                            • ファインディでのGitHub Actions自動化の事例 - Findy Tech Blog

                                              ファインディ株式会社でフロントエンドのリードをしております 新福(@puku0x)です。 GitHub Actionsは、CI/CD以外にも様々な業務の効率化に役立ちます。 この記事では、弊社で実施しているGitHub Actionsを使った自動化について紹介します。 自動化 担当者アサイン ラベル設定 リリース QAチェック項目の抽出 定期実行 まとめ 自動化 担当者アサイン 開発フローの中では、Pull requestを作ってからレビューに出すまでにいくつかのタスクを行うことがあります。 弊社では、Pull requestの作成者がAssignee(担当者)となる場合が多いため、↓こちらのActionを用いてアサインの自動化をしています。 github.com - uses: kentaro-m/auto-assign-action@v2.0.0 with: repo-token: $

                                                ファインディでのGitHub Actions自動化の事例 - Findy Tech Blog
                                              • EKSでKubernetes DaemonSetを用いたロギング:Fluent-bitの運用とトラブル事例 - MonotaRO Tech Blog

                                                モノタロウのプラットフォームエンジニアリング部門 コンテナ基盤グループの宋 明起です。 私たちは、アプリケーション開発者からコンテナシステムの認知負荷を取り除き、アプリ開発に専念できるコンテナ基盤の構築と基盤を改善し、開発者はより楽に、より安全にアプリケーションのデプロイと運用できるように支援しています。 背景 基本設計 方針 構成 サンプル モニタリング サンプル 障害 障害1. Memory overflowエラーが発生 障害2. 大量のログが欠損になっている (refresh_interval) 障害3. まだ一部ログが欠損になっている (Prestop) [FAQ] 背景 モノタロウでは以下の記事にあるようにバックエンドのAPIをコンテナ化から始め様々なレイヤーの様々なアプリケーションをEKSの上で運用しています。 EKSコンテナ移行のトラブル事例:ALBの設定とPodのライフサイ

                                                  EKSでKubernetes DaemonSetを用いたロギング:Fluent-bitの運用とトラブル事例 - MonotaRO Tech Blog
                                                • GitHub Actionsを活用したワークフローのコツと教訓 - RAKUS Developers Blog | ラクス エンジニアブログ

                                                  こんにちは、あるいはこんばんは。 だいたいサーバサイドのエンジニアの(@taclose)です☆ GitHub Copilotが活躍している昨今、弊社ではGitHubで更に開発効率を良くしていこうという流れで日々自動化が行われております。 今回はそんな時代だからこそ求められているGitHub Actionsについて、初心者向けにワークフロー作成の際に知っておきたいコツと教訓について紹介します。 GitHub Actionsのワークフローを読めるけど、まだ自信がないという方はぜひ参考にしてください! 「それもっと早く知っておきたかった!」「初心者がつまづきがちなポイント!」を解説します! 読者ターゲット ワークフロー作成のコツ 1. run セクションで式 ${{}} は極力使わない 危険その1:コードインジェクションのリスク 危険その2:データのサニタイズ不足 2. workflow_cal

                                                    GitHub Actionsを活用したワークフローのコツと教訓 - RAKUS Developers Blog | ラクス エンジニアブログ
                                                  • Railsアプリの自動テスト環境をCirlceCIからGitHub Actionsへ移行したときにやったこと - ZOZO TECH BLOG

                                                    はじめに こんにちは、WEARバックエンド部バックエンドブロックの塩足です。普段は弊社サービスであるWEARのバックエンド開発・保守を担当しています。 WEARのバックエンドでは、これまで自動テスト環境としてCircleCIを使用していましたが、運用保守の改善を目的にGitHub Actionsへ移行しました。 今回は、GitHub Actionsへ移行する際に取り組んだ以下の3点について紹介します。 効率的にテストを分割してテストを並列実行する方法 失敗したテストのみを再実行する仕組みの構築 GitHubのCheck annotationsを活用して、失敗したテスト情報を表示 また、最後に今回行ったテストカバレッジのレポーティングとGitHub Pagesでのホスティングの方法について紹介します。 目次 はじめに 目次 背景 なぜ自動テスト環境をCircleCIからGitHub Acti

                                                      Railsアプリの自動テスト環境をCirlceCIからGitHub Actionsへ移行したときにやったこと - ZOZO TECH BLOG
                                                    • 静的サイトのCI/CDでも侮るなかれ!Docs as Codeに沿ったセキュアな開発プロセスの実践/secure-docsascode-cicd-for-static-sites

                                                      「ServerlessDays Tokyo 2024」での登壇資料です。 イベントURL:https://serverless.connpass.com/event/325659/

                                                        静的サイトのCI/CDでも侮るなかれ!Docs as Codeに沿ったセキュアな開発プロセスの実践/secure-docsascode-cicd-for-static-sites
                                                      • AWSでのDevSecOps~セキュリティ運用/実装~ - Adwaysエンジニアブログ

                                                        広告事業本部でリードデータエンジニアを行なっている大窄 直樹 (おおさこ)です. 前回は, AWSでのログ設計/実装に焦点を当てたブログを書きました. 今回は, AWSでのセキュリティ運用/実装に関する内容をお届けしようと思います! セキュリティ運用は難しいですよね. 日々新たな脆弱性が次々と発見されており, 脆弱性自体に気づくのも一苦労です. それに加えて, 対応してもお金を生み出すわけではないため, 過剰な対応をするわけにもいかず, 悩ましいところです(笑) 概要 このブログでは, セキュリティの考え方, 及びAWSでDevSecOpsを行う一手法を紹介します. 利用するサービスは以下のとおりです. Security Hub Amazon Inspector Snyk これらのサービスを使うことで, 開発, セキュリティ, 運用を密接に結びつけ, 効率的なセキュリティ運用を試みます.

                                                          AWSでのDevSecOps~セキュリティ運用/実装~ - Adwaysエンジニアブログ
                                                        • 来園者「キリンとチーター一緒に展示してるんだって!キリン食べられちゃわないのかな?」チーター「ムリです」

                                                          空白寺 @vanity_temple 来園者「キリンとチーター一緒に展示してるんだって!キリン食べられちゃわないのかな?」 チーター「ムリです」 pic.x.com/ktzy4ci3th リンク 東洋経済オンライン 横浜「キリンとチーター」が共存する動物園の今 ズーラシアの正式名称は「横浜市立よこはま動物園」。「ズーラシア」は愛称で、公募で選ばれた。1999年開園と、首都圏の動物園の中では新しい。公立であることが意外に思えるほど、テーマパークのような楽しさに溢… 3 users 98 ここの見どころはなんといっても、キリン、グラントシマウマ、エランド、チーターの4種の動物が同じ柵の中で飼育されている「4種混合展示」だ。草原で俊足を活かして狩りを行うことで知られているチーターが、他の草食動物に食いついてしまわないのかと心配になるが、チーターは自分の身体より大きな動物は襲わないことが分かってい

                                                            来園者「キリンとチーター一緒に展示してるんだって!キリン食べられちゃわないのかな?」チーター「ムリです」
                                                          • 業務システムのモダナイズを始めました〜RoRからFastAPI × next.jsへ

                                                            はじめに この記事では、詳細な技術の話は割愛しています。 「なぜモダナイズをやろうと思ったのか?」 「どんな課題意識があったのか?」 「具体的にどうプロジェクトを進めてきたのか?」 といった、課題設定・意思決定のプロセスに重点を置くことで、同じような境遇にあるチームの意思決定の材料になればと思っております。 RoRの限界...? ダイレクト出版の業務システムはRoR(v6.1)で動いてきました。リリースから6年ほど経っているでしょうか。このシステムは何をするものかというと、例えば、 商品を管理する 顧客を管理する 注文内容を設定する 一斉配信メールを送信する マーケティングオートメーションを設定する 各種分析を行う など、業務に関わるありとあらゆることを行っています。ソースコードは10万行程度で、中堅システムといった具合でしょうか。 実はこのシステム、そこまでレガシーというわけではなく、テ

                                                              業務システムのモダナイズを始めました〜RoRからFastAPI × next.jsへ
                                                            • 初めてのSREから3年半でやったことの振り返り

                                                              レバテック開発部DevOps推進グループSREチームの蒲生です。 このたびレバテックを退職することになりました。 今までやってきたことを振り返ることで、お前普段なんもやってなかったやろと思っている方への説明とまだまだやらなアカンことあるけど許してねって気持ちを吐き出したいなと思います。 初めてSREとして働き始めてからレバテック事業でのSREチーム結成、活動していくまでで「やってよかったな」と思ったことを紹介していきます。(僕個人ではなくチームでの取り組み) 「こうしておけばよかったな」という懺悔も混ぜておきます。 1. 監視体制作り 初めてのSREだったので定石通り、こちらのピラミッド通りにプラクティスを実践しました。 (O’Reilly Site Reliability Engineeringより) 簡単な状況 監視設定はCloudWatch CDKでリソースのCPUやメモリ、スレッド

                                                                初めてのSREから3年半でやったことの振り返り
                                                              • GoでKubernetesクラスター上にモックリソースをサクッと構築するOSSを開発しました - ZOZO TECH BLOG

                                                                はじめに こんにちは。株式会社ZOZOのSRE部プラットフォームSREチームに所属しているはっちーと申します。 本記事では、Kubernetesクラスター上にモックリソースをサクッと構築する「モック構築ツール」を紹介します。ZOZOの事例をもとにした説明となりますが、Kubernetesクラスター上での負荷試験やフロントエンド開発などの効率化において広く一般的に活用できるツールのため、OSSとして公開しています。GitHubリポジトリは以下です。 github.com 本ツールは、私個人のOSSとして管理しています。ZOZOでは、社員がOSS活動しやすいように、「業務時間中に指示があって書いたソフトウェアでも著作権譲渡の許諾によって個人のものにできる」というOSSポリシーがあります。ありがたいです。 techblog.zozo.com 目次 はじめに 目次 モック構築ツールとは 開発のきっ

                                                                  GoでKubernetesクラスター上にモックリソースをサクッと構築するOSSを開発しました - ZOZO TECH BLOG
                                                                • チームで培われたベストプラクティスをlintとして周知する - エムスリーテックブログ

                                                                  こんにちは。AI・機械学習チームの氏家(@mowmow1259)です。 エムスリー福岡オフィスの一人目のエンジニアとして福岡で働いています。 マクドナルドの月見バーガーが好きで、今年も発売開始当日に食べに行きました。 私が所属するAI・機械学習チームでは基本的に2週間から1ヶ月程度で新規プロダクトをリリースするなど、高速にプロダクトを開発しています。 その過程で、「この書き方は落とし穴があるから使わない方がいい」といった開発に際したベストプラクティスが溜まっていきます。 そういったベストプラクティスはレビューでの指摘や技術共有会*1でチームに浸透してきますが、レビュー負荷や新メンバーへの周知などに課題がありました。 この記事では、それを解決するためにベストプラクティスをLinterの独自ruleとして規定し、CIで自動検知することでチーム全体に周知する取り組みについて紹介します。 独自ru

                                                                    チームで培われたベストプラクティスをlintとして周知する - エムスリーテックブログ
                                                                  • さらなる進化を遂げた「uv」の新機能 | gihyo.jp

                                                                    福田(@JunyaFff)です。本連載Python Monthly Topicsで2024年3月に公開したRust製のPythonパッケージ管理ツール「uv」を使ってみよう で紹介した「uv」が、さらなる進化を遂げました。今回は、その新機能を紹介します。 はじめに Astral社が開発するRust製の高速なpipの代替ツール「uv」がパッケージマネージャーとして8月にアップデートされました。pipの代替ツールとしてだけでなく、Pythonプロジェクト、コマンドラインツール、単一ファイルスクリプトさらにPython自体を管理できるようになりました。uvは、pipやpipx、venv、poetryやpyenvのような機能を包括していると言え、そしてそのすべてが非常に高速に動作します。 本記事では、アップデートした「uv」の新機能を中心に紹介します。 基本的な使い方は Rust製のPythonパ

                                                                      さらなる進化を遂げた「uv」の新機能 | gihyo.jp
                                                                    • BunでNode.jsのツールをSingle-file executable binaryにしてバイナリを配布する

                                                                      Secretlint v8.3で、単体のバイナリファイルとしてsecretlintコマンドを配布するようにしました。 Release v8.3.3 · secretlint/secretlint どういうことができるようになるかというか、Node.jsをインストールしなくてもsecretlintコマンドを使えるようになります。 次のようにCurlでダウンロードして実行するだけで、機密情報の検出ができるようになります。 #!/usr/bin/env bash set -euo pipefail SECRETLINT_VERSION="8.3.3" # secretlintのバージョン ARCH=$(uname -m) OS=$(uname -s | tr '[:upper:]' '[:lower:]') # Map architecture to the expected format ca

                                                                        BunでNode.jsのツールをSingle-file executable binaryにしてバイナリを配布する
                                                                      • TerraformのCIをAtlantisに移行しました - Repro Tech Blog

                                                                        Repro では AWS 等のリソース管理に Terraform を活用しています。 この度 Terraform で管理しているコードの CI を Atlantis に移行したので、その経緯などについて書きます。 背景 Repro では以下のリソースを Terraform を使ってコード化して GitHub で管理しています。 AWS で構築したインフラ DataDog のモニターやアラート Google Cloud Platform で利用している一部のリソース GitHub の reproio organization のメンバーやチーム Kafka Topic MySQL アカウント PagerDuty の通知まわりの設定 Rollbar の通知 移行前は CircleCI や AWS CodeBuild を活用して独自に CI を構築していました。 課題 初期から CicleCI

                                                                          TerraformのCIをAtlantisに移行しました - Repro Tech Blog
                                                                        • 「DevOpsチーム向けCI/CD」のベストプラクティス12選

                                                                          TechTargetは2024年8月8日(米国時間)、「DevOpsチーム向けCI/CD(継続的インテグレーション/継続的デリバリー)のベストプラクティス」に関する記事を公開した。CI/CDパイプラインを構築して管理するには、自動化を連鎖させるだけでは不十分だ。開発とデプロイメントの取り組みを最大限に高めるため、本稿で説明するCI/CDのアプローチを参考にしてほしい。 CI/CDのベストプラクティスは幾つかあるが、プロジェクトによって“何が最適か”は異なる。プロジェクトの目標に応じて、「セキュリティ」「自動化」「リリースまでの時間」のいずれか一つを選ばなければならない場合もある。「早い段階で失敗する」戦略は安全性の面で懸念があるが、リリースまでの時間を優先するチームにとっては価値がある。チームはプロジェクトの優先順位と制約に基づいて、さまざまな自動テストツールを選択することもできる。 De

                                                                            「DevOpsチーム向けCI/CD」のベストプラクティス12選
                                                                          • [アップデート] AWS CloudFormation の Git 同期機能がプルリクエストにスタック変更内容をコメントしてくれるようになりました | DevelopersIO

                                                                            [アップデート] AWS CloudFormation の Git 同期機能がプルリクエストにスタック変更内容をコメントしてくれるようになりました いわさです。 AWS CloudFormation は Git リポジトリとスタックを同期させて、簡易的な CI/CD 環境を用意することが出来ます。 今朝のアップデートでこちらが強化され、CloudFormation がプルリクエストにスタックへの変更内容をコメントしてくれるようになりました。 Git 同期では CloudFormation が特定のブランチを監視し、変更が発生すると自動でスタックがプロビジョニングされるような動きとなっているのですが、このアップデートではユーザーが作成したプリリクエストのマージ先が監視対象のリポジトリだった場合、マージ前でスタック変更セットの内容をプルリクエスト上でコメントしてくれます。 これによってレビュー

                                                                              [アップデート] AWS CloudFormation の Git 同期機能がプルリクエストにスタック変更内容をコメントしてくれるようになりました | DevelopersIO
                                                                            • AWS CDKを用いたセキュアなCI/CDパイプラインの構築 / Build a secure CI/CD pipeline using AWS CDK

                                                                              JAWS-UG CDK支部 #16 ~CDK Conference 2024 Extra~ https://jawsug-cdk.connpass.com/event/328676/

                                                                                AWS CDKを用いたセキュアなCI/CDパイプラインの構築 / Build a secure CI/CD pipeline using AWS CDK
                                                                              • 現場から学ぶMLOps: MonotaROでの実践的アプローチ~オンライン推論編~ - MonotaRO Tech Blog

                                                                                はじめに こんにちは。MonotaROで機械学習エンジニア兼、Tシャツのモデルを務めている新卒3年目の長澤です! 最近は健康のためにスポーツをしているのですが、そのスポーツの疲れで日々が辛くなってきました。観戦と自分で身体を動かす方の割合(重み)をバンディットを使ってうまく最適化していきたいこの頃です。 今回は、自分がここ1,2年(2023~2024)で取り組んできたMonotaROにおけるMLOpsの取り組みについて、実例を交えながら紹介します。MLOpsの実例はあまり世の中に出回っていないので、一つの事例として読んでもらえれば嬉しいです。 はじめに この記事で紹介すること この記事で紹介しないこと MonotaROにおける機械学習エンジニア パーソナライズドランキングとは MLOpsに取り組むにあたっての背景と課題 MLOpsのプロジェクトスタート時 MLOpsとりあえず始めてみる期

                                                                                  現場から学ぶMLOps: MonotaROでの実践的アプローチ~オンライン推論編~ - MonotaRO Tech Blog
                                                                                • terrraformを使ったGoのLambdaの管理 - カンムテックブログ

                                                                                  SREの菅原です。 カンムのサービスはWebサービス・バッチ処理なども含めて基本的にはECS上で動かしているのですが、簡単なバッチ処理はLambda+EventBridge Schedulerの組み合わせで動かすこともあります。 LambdaはECSに比べてDockerイメージのビルドやECRの準備が不要で作成の手間が少ないのですが、terraformでデプロイまで含めて管理しようとすると少し問題がありました。 terraformでのLambdaのデプロイの問題点 例えば以下のような構成のNode.jsのLambdaをデプロイする場合 / ├── lambda.tf └── lambda ├── app.js ├── package-lock.json └── package.json // app.js const util = require("util"); const gis =

                                                                                    terrraformを使ったGoのLambdaの管理 - カンムテックブログ