並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 610件

新着順 人気順

circleciの検索結果1 - 40 件 / 610件

circleciに関するエントリは610件あります。 github開発CI などが関連タグです。 人気エントリには 『Nスタのキャスター固まらせた、怒りの発言「倉持先生」がトレンド1位 - 芸能 : 日刊スポーツ』などがあります。
  • Nスタのキャスター固まらせた、怒りの発言「倉持先生」がトレンド1位 - 芸能 : 日刊スポーツ

    3日夕に放送されたTBS系報道番組「Nスタ」で、インターパーク倉持呼吸器内科院長の倉持仁氏が、菅義偉首相と小池百合子都知事に「2人とも至急お辞めになった方がいい」と怒りの発言をし、「倉持先生」がツイッターのトレンド1位にランクインした。 コロナ患者の入院対象を重症者らに限定し、重症化リスクが低い中等症患者は自宅療養とするという政府の方針転換を受け、コロナ治療の最前線にいる立場から「言っていることがめちゃくちゃ」と語った。 倉持医師は、「中等症2とかで治療に介入していてはもう間に合わない。より早い段階で治療に介入しなければいけないので抗体カクテル療法を承認したはず。その治療は軽症者のうちにしなければならないが、入院しなければ薬は使えない。言っていることがめちゃくちゃです」。 菅首相、小池都知事について「この2人がおっしゃっていることというのは、国民にまっとうな医療体制を供給しませんよというメ

      Nスタのキャスター固まらせた、怒りの発言「倉持先生」がトレンド1位 - 芸能 : 日刊スポーツ
    • 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

        Docker創始者らが開発、ビルド/テスト/デプロイの自動化をポータブルにするツール「Dagger」登場。そのままローカルでもGitHubでもCircleCIでも実行可能に
      • プログラミング初学者のための「即戦力ノウハウ」(4 万字) - Qiita

        はじめに これは文系出身の私が、入社後に早く教えて欲しかったことをまとめたものです。 私は 10 年ほど前に文系大学を卒業して技術職で採用されましたが、入社 1 年も経たないうちに「使えない」と言われ、お客様向けのサポートセンター業務に就くことになりました。 その間も個人ではコーディングを続け、開発チームに厄介な口出しなどしているうちに、いつの間にか技術職に戻っていました。 プログラミング未経験者のよくある回り道をした身として、同じような境遇の方の助けになれば幸いです。 以下はすぐに使えるものから、未経験の方には難しい内容まで含まれます。 すぐに分からなくても知ってさえいれば後々効いてくる内容にしたつもりですので、「そのうち分かるかな」くらいの気持ちで読んでもらえればと思います。 👑 コーディングの基礎テクニック 初学者に役立つ汎用的なテクニックをまとめます。 特に説明のない限り、コード

          プログラミング初学者のための「即戦力ノウハウ」(4 万字) - Qiita
        • 期限の制約なく無料で使えるクラウド「Free Tier」主要サービスまとめ。2022年版

          いくつかのクラウドサービスでは、1年程度の無料トライアルや一定額のクーポンなどに加えて、期間の制限なくずっと無料で使える、いわゆる「Free Tier」や「Always Free」と呼ばれる無料枠のサービスが提供されています。 こうした無料枠は試行用の環境や一時的なテスト環境などとして、期間を気にせずサービスを試すうえで非常に有効です。 本記事では期限の制約なく無料で提供されている主なクラウドサービスを、2022年版としてまとめました。 ただしこれらの無料提供サービスは提供側の都合によって終了することもあり得ます。また、最近では半導体不足などの影響でクラウドのサーバリソースなどが不足がちのためか、無料枠の申し込みが制限される場合もありますので、それらに留意して利用しましょう(一部では無料枠が空いたらすかさず取得する自動スクリプトなども出回っているそうです)。 Amazon Web Serv

            期限の制約なく無料で使えるクラウド「Free Tier」主要サービスまとめ。2022年版
          • 【マジで】サイバー演習シナリオの作り方【怖い】 - freee Developers Hub

            「CEOに身代金を要求したい」 こんにちは、PSIRTマネージャのただただし(tdtds)です。この記事はfreee Developers Advent Calendar 2021 18日目です。 freeeにjoinしてから早くも14ヶ月がすぎました。freeeでは毎年10月に全社障害訓練をしていて、昨年は入社したてで右も左もわからないままAWS上の本番環境(のレプリカ)に侵入してDBをぶっ壊す役目をさせられたのも良い思い出です*1。 で、上の「CEOに身代金を要求したい」という物騒な相談は、今年の訓練計画の話です。話を持ち掛けてきたのはCIOの土佐。昨年は主要サービスが落ちて、開発チームが対応にあたる中、ビジネスサイドも顧客対応などで訓練参加しましたが、今年はさらに、経営サイドまで巻き込もうというゴール設定がされたわけですね。腕が鳴ります。 ゴールは「CEOに4BTCを要求する」 ゴー

              【マジで】サイバー演習シナリオの作り方【怖い】 - freee Developers Hub
            • 自動化大好きエンジニアたちが語る、効率化・品質向上 Tips【26選】 - RAKUS Developers Blog | ラクス エンジニアブログ

              こんにちは、技術広報のyayawowoです。 「自動化(オートメーション/Automation)」 今、この言葉を聞いて胸がときめいた方に必見です! 当社主催イベントでも人気の高い 「自動化大好きエンジニアLT会」全5開催分の資料をまとめて紹介します! イベント詳細はこちらをご確認ください! ・自動化大好きエンジニアLT会 ・自動化大好きエンジニアLT会 - vol.2 ・自動化大好きエンジニアLT会 - vol.3 ・自動化大好きエンジニアLT会 - vol.4 ・自動化大好きエンジニアLT会 - vol.5 目次 目次 手動テストやインフラ構築は自動化しよう APIテスト品質を向上させる Datadog Synthetic Monitoring APIテスト自動化とテストピラミッド TestLinkにテスト結果を自動的に登録 Cypressでサクッと始めるE2Eテスト 自動テスト環境を

                自動化大好きエンジニアたちが語る、効率化・品質向上 Tips【26選】 - RAKUS Developers Blog | ラクス エンジニアブログ
              • 数時間かかる週一リリースを毎日何度も爆速でできるようにするまで / CI/CD Conference 2021

                CI/CD Conference 2021

                  数時間かかる週一リリースを毎日何度も爆速でできるようにするまで / CI/CD Conference 2021
                • GitHub Actions 逆引きリファレンス

                  1.この記事の立ち位置#自分がいつも調べていること、忘れがちな Tips や小ネタを列挙していく。そのため、網羅性は重視しない。 というのも、なにか調べていていろいろ読み漁った挙げ句、1周回って行き着くところは GitHub Actions の公式ドキュメントであり、たとえば Workflow の書き方は以下のページをよく開いている。 Workflow syntax for GitHub Actions - GitHub Docs それでも、公式ドキュメントで参照したい箇所を引っ張るための用語を知るまでに苦労することが往々にあり、この記事が、公式ドキュメントで参照したい箇所を導くための助けとなればと思い、書いていく。 2.Step と Job と Workflowの違いアレコレ#2-1.Step と Job と Workflow の違いの一行まとめ#Step < Job < Workflo

                  • 20代後半から始める英語習得

                    最近GoogleやMicrosoft、Amazonなどの大手の外資企業以外にも日本でソフトウェアエンジニアの採用することが増えてきた気がします。Twitterのタイムラインを見ても、海外に本社があり、英語を利用して働いている方がをちらほら見かけるようになってきました。年俸的にも外資の企業は魅力だったりしますが、管理職以外でソフトウェアエンジニアとして働き続けることを考えた際に、IC(Individual Contributor)というパスが日本の企業よりも、外資企業の方が明確なキャリアパスとして存在するというもの理由の一つな気がします。 私は現在CircleCIというCI(Continuous Integration:継続的インテグレーション)を支えるためのサービスを提供している企業でインフラストラクチャーエンジニアをしています。最初はサポートエンジニアとして入社し、1年くらい前にインフラ

                      20代後半から始める英語習得
                    • 期限の制約なく無料で使えるクラウド「Free Tier」主要サービスまとめ。2023年版

                      いくつかのクラウドサービスでは、新規ユーザーに対する1年程度の無料トライアルや一定額のクーポンなどの提供だけでなく、期間の制限なくずっと無料で使える、いわゆる「Free Tier」や「Always Free」と呼ばれるサービスが提供されています。 こうしたサービスは試行用の環境や一時的なテスト環境、あるいはホビー用途などに適しています。 本記事では期限の制約なく無料で提供されている主なクラウドサービスを、2023年版としてまとめました(新規ユーザーとして期限の制約なく無料で使えるものを優先しています)。 ただしこれらの無料のサービスは、提供側の都合によって申し込みや利用が制限されたり、もしくは提供自体が終了したりすることがあります(昨年、多くのITエンジニアに人気であったHerokuのFreeプランが終了したことをご記憶の読者も多いでしょう)。 無料のサービスを利用する場合には、そうした提

                        期限の制約なく無料で使えるクラウド「Free Tier」主要サービスまとめ。2023年版
                      • NewsPicksにCTOとして入社して1年でDX Criteriaを大幅改善した話 - Uzabase for Engineers

                        こんにちは。このブログでは初めまして。2020年の2月にNewsPicksに入社した高山です。 今回は僕がNewsPicksのCTOになってからの1年でやったお仕事について書いていきます。 CTO最初のミッション DX Criteriaについて 「デプロイ回数」を定点観測 やってきたチャレンジ 1年経ってみて CTO最初のミッション NewsPicksは2013年に誕生し、5年ほどの壮大な創業期の間にたくさんの新しい領域に挑戦しており、僕が入社したときには既に事業面でもシステム面でも「それなりの複雑さ」という感じでした。 前任CTOの杉浦さん(今はグループ内でアメリカでの新規サービスの立ち上げをしています)からバトンを受け取って最初のミッションが「DX Criteriaを上げること」だと聞いたときにそのあたりの事情を全て察しました。😅 結論から先に書くと、1年で大幅改善を達成することがで

                          NewsPicksにCTOとして入社して1年でDX Criteriaを大幅改善した話 - Uzabase for Engineers
                        • 7年続いたサービスをEC2構成からECS構成へ乗り換えた話 - KAYAC engineers' blog

                          この記事は Tech KAYAC Advent Calendar 2021 の20日目の記事です。 こんにちは、バックエンドエンジニアの @commojun です。今年のTech KAYAC Advent Calendarは3度めの参戦です!よろしくお願いいたします! 本日の記事は、昨年の記事の続きで、Amazon EC2のプロダクトをAmazon ECS構成へと乗り換えた話になります! techblog.kayac.com 目次 目次 背景 Amazon Linuxのサポート終了 ついでにPerlのバージョンもあげた 苦労したポイント 1,デプロイ方法がめっちゃ変わる デプロイのために都度コンテナイメージを焼く 2階建て作戦 2,batchサーバどうするの問題 sqsjfr + SQS + sqsjkr 作戦 3,泥臭い戦い ecspressoの存在 非エンジニアにもわかってもらおう 「

                            7年続いたサービスをEC2構成からECS構成へ乗り換えた話 - KAYAC engineers' blog
                          • Github Actions チートシート

                            概要 何度も調べて何度もテストしたりしたので、多用するものをまとめていきたい。 項目 push時に実行 // feature/aaaで動く。 feature/aaa/bbbでは動かない on: push: branches: - feature/* // feature/aaa, feature/aaa/bbbで動く on: push: branches: - feature/** // なにかしらのtagがpushされたときに実行、branchのpushは無視 on: push: tags: [ '**' ] branches-ignore: [ '**' ] // 指定したpathの変更だけでは実行しない on: push: branches: - main paths-ignore: - '*.md' - 'docs/**' on: workflow_dispatch: inputs

                              Github Actions チートシート
                            • 大きなGitリポジトリをクローンするときの工夫を図解します - DeNA Testing Blog

                              こんにちは、SWETでCI/CDチームの前田( @mad_p )です。 SWETではCI/CDチームの一員として、Jenkins運用のサポートや、CI/CD回りのノウハウ蓄積・研究をしています。 はじめに Gitリポジトリをクローンすると、ローカルフォルダにはそのリポジトリの全体がダウンロードされ .git というフォルダに格納されます。ブランチをチェックアウトすると、ブランチ内のファイルがワーキングツリーとして展開されます。この様子を図にするとこのようになります。 この .git とワーキングツリーの使うディスク容量を節約しようというのが今回のお話です。特にJenkinsにおいて、大きめのGitリポジトリをクローンしてくる場合に課題があり、いろいろ工夫してみたので、その結果を紹介します。同じCI/CDチームの加瀬による記事「大規模リポジトリで高速にgit cloneするテクニック」と内容

                                大きなGitリポジトリをクローンするときの工夫を図解します - DeNA Testing Blog
                              • rjとtとjqコマンドでHTTPレスポンスを試験する - ゆーすけべー日記

                                Web 開発者は HTTP レスポンスをよく見る。 以前 CDN を導入する際に、キャッシュがヒットしているかどうか、どこのエッジがキャッシュを返しているかを確認するためにヘッダをよく見ていた。また、ヘッダだけではなく、TTFB といったレスポンスタイムも気にしている。とにかく HTTP レスポンスをよく見る。 HTTP レスポンスを確認する3つの方法 Chrome さえあれば DevTools を見て一目瞭然である。 とはいえ、コマンドラインで確認したい時がしばしばある。 GUI を操作するよりも手軽である。 その場合はcurlコマンドを叩けばよい。 これでプロトコル、ステータス、ヘッダが分かる。 また、レスポンスタイムを測りたければ、その名もttfb.shというcurlをラップしたコマンドラインツールがある。 https://github.com/jaygooby/ttfb.sh この

                                  rjとtとjqコマンドでHTTPレスポンスを試験する - ゆーすけべー日記
                                • 入門 GitHub Actions - メドピア開発者ブログ

                                  CTO室SREの @sinsoku です。 社内のGitHub ActionsのYAMLが複雑になってきたので、私が参考にしてる情報や注意点、イディオムなどをまとめておきます。 頻繁に参照するページ 新しい機能の説明が日本語ページに反映されていないため、基本的に英語ページを読むことを推奨。 ワークフロー構文 YAMLの基本構文の確認 コンテキストおよび式の構文 github オブジェクトの情報、関数の確認 ワークフローをトリガーするイベント 各イベントの GITHUB_SHA と GITHUB_REF が記載されている About GitHub-hosted runners インストールされているSoftwareのバージョンなどが記載されている GitHub REST API APIを使うときに参照する よく使うaction actions/checkout イベントによってはデフォルトブ

                                    入門 GitHub Actions - メドピア開発者ブログ
                                  • アルパカ証券 技術ノート|アルパカ証券の裏側 - はじめに

                                    こんにちは。shirou(@r_rudi) と申します。アーキテクトという名の雑用係をしています。 Alpaca Japanでは、2021年8月に「アルパカ証券」という証券サービスをはじめました。 この一連の文章は、アルパカ証券の裏側のシステムやその開発体制などについて述べたものです。なるべく証券分野に限らず説明していく予定ですので、証券サービスを立ち上げようとしている人たちにはもちろん、それ以外の方にも参考にしていただけるような文章を目指したいと思っています。 アルパカ証券とはアルパカ証券の詳細はホームページをご覧ください。また、第一種金融商品取引業者登録完了時のプレスリリースにも、「アルパカ証券」サービスの特徴が記載されています。 全体設計方針まず最初に、アルパカ証券を構成するシステムの全体設計方針について説明します。 マイクロサービス vs モノリシック設計は2018年中頃ぐらいから

                                      アルパカ証券 技術ノート|アルパカ証券の裏側 - はじめに
                                    • 秒間3万リクエストをkubernetesでさばく - Gunosy Tech Blog

                                      こんにちは!スタンディングデスクを導入して快適な開発環境と運動不足の両方を解消できるようになったのではと感じている、広告技術部のUT@mocyutoです。 今回は半年ほどEKSを運用して秒間3万リクエストのトラフィックをさばくほどになりました。 秒間3万は広告システムだと割とあるとは思いますが、kubernetesでも運用できているので紹介しようと思います。 対象のEKSで構築したサービスは広告の配信サーバです。 広告配信サーバの要件として、まず50ms以内にレスポンスを返さなければいけません。 構築したk8sのレスポンスタイムの99パーセンタイルは10msほどで返せています。 以下は必要最小限のクラスタの構成図です。 全体像 API 弊社のサーバサイドはほぼGoで作られているので、例に漏れずGoで作られています。 pod構成はAPI、fluentd、envoyの サイドカーパターン です

                                        秒間3万リクエストをkubernetesでさばく - Gunosy Tech Blog
                                      • ソフトウェアテストで参考にしている67のモノ 2021 #scrumniigata|kyon_mm

                                        ソフトウェアテストの学び方に関して書籍やウェブサイト、そしてそこから伸びる某かについて自分なりにまとめ直してみるかーと。思いました。これを全部読めとかではなくて、まぁ自分が今まで読んできて役に立ったものリストくらいの感じです。 また、このリストの解説をスクフェス新潟でプレゼンしたいと思い公募に出しました。リンク先でLikeしてもらえるとプレゼンできる確率が上がるのでよければぜひ押していってください。 ソフトウェアテストで参考にしている67のモノ #scrumniigata https://confengine.com/conferences/scrum-fest-niigata-2022/proposal/16369/67 まずは、リストを。後半に各カテゴリの所感とかを。 発端は先日、Twitterでリプライをいただいて、7年近く前に「テストエンジニアの品格」という煽ったプレゼンをしていた

                                          ソフトウェアテストで参考にしている67のモノ 2021 #scrumniigata|kyon_mm
                                        • 最近 Fitbit つけて散歩してるので CircleCI + Pixela で見えるようにしてみた - Mitsuyuki.Shiiba

                                          歩数で草を生やしてみたのだー。これで散歩の楽しみが増えたなー やってること やってることはシンプルで、こう↓ Fitbit の API で歩数を取得 Pixela に記録 というスクリプトをつくって CircleCI で定期的に実行 Fitbit? 最近 Fitbit Sense というスマートウォッチをつけて散歩してる www.fitbit.com 会社の福利厚生で健康のための補助があるので、それを利用して手に入れたのだ。散歩やジョギングをしたら勝手に記録されてるので便利。睡眠のログも取られてるので面白い Pixela? Pixela は日々の活動を記録して見えるようにしてくれる API サービス。いちばん最初に貼った画像みたいに GitHub の草を生やすやつみたいにしてくれる。操作が全部 API 経由なのも楽しい pixe.la せっかく散歩してるから せっかく散歩してるから Fit

                                          • https://tech.pepabo.com/2021/03/03/ec_efficiency_with_github_actions/

                                              https://tech.pepabo.com/2021/03/03/ec_efficiency_with_github_actions/
                                            • 毎日何度も本番環境にデプロイをしている話 - Mitsuyuki.Shiiba

                                              CircleCI に入って色々と面白いなぁって思いながら毎日楽しんでる。その楽しんでることのひとつに Git のブランチモデルがある。最初はびっくりしたけど、慣れるととても良い 最初に言っておくと、この手法がどこにでも当てはまるとは思ってない。業種や、開発形態、プロダクトのタイプなどによって合うやり方は違う。単に CircleCI には、この手法がとても合ってるなぁと思う トランクベースのブランチモデル タスクに着手するときは、まずメインブランチからそのタスク用のブランチを作る。develop ブランチや release ブランチみたいな長く生きてるブランチはない。そのタスク用のブランチにコミットをプッシュしたらプルリクエストを出す。そして、レビューが終わればメインブランチにマージされる。タスクに着手してからマージまで、はやければ1時間ぐらい。長くてもだいたい2,3日くらい そして、メイン

                                                毎日何度も本番環境にデプロイをしている話 - Mitsuyuki.Shiiba
                                              • GitHub ActionsにおけるStep/Job/Workflow設計論

                                                この記事について GitHub Actionsには、以下3つの実行単位が存在します。 Workflow Job Step パイプラインを組む中で出てくる複数個の処理を、1つの実行単位でまとめてしまうか、それとも分割するのかというのは悩むポイントかと思います。 一つのstepのrunフィールドにコマンドを詰め込む?それともstepを分けた方がいい? 一つのJobの中のstepとして記述した方がいい?それとも別のJobに定義した方がいい? 一つのWorkflowの中にJobをたくさん定義する?それともWorkflowを別にする? この記事では、Workflow・Job・Stepそれぞれの性質を踏まえた上で、ベストな処理単位の選び方を考察します。 使用する環境・バージョン GitHub Actions: 2022/5/15時点での機能をもとに考察 読者に要求する前提知識 GitHub Actio

                                                  GitHub ActionsにおけるStep/Job/Workflow設計論
                                                • なんとなくから脱却する GitHub Actionsグッドプラクティス11選 | gihyo.jp

                                                  本記事のテーマはGitHub Actionsです。個人的に「もっと早く知りたかった!」と考えているグッドプラクティスを、厳選してお届けします。想定読者は次のとおりです。 普段GitHub Actionsを雰囲気で運用している人 GitHub Actionsをコピペや生成AIで乗り切っている人 他者が書いたコードの意味をより深く理解したい人 本記事でGitHub Actionsの基本は説明しません。グッドプラクティスを含めて基礎から学びたい人は、拙著『GitHub CI/CD実践ガイド』を読んでみてください。GitHub Actionsの基本構文から運用のコツまで、網羅的に解説しています。さて書籍紹介はこれぐらいにして、さっそく本題へ進みます。 GitHub Actionsの設計指針 GitHub ActionsはCI/CDや各種自動化で役立つ、汎用的なワークフローエンジンです。一般的に長期

                                                    なんとなくから脱却する GitHub Actionsグッドプラクティス11選 | gihyo.jp
                                                  • Makefile覚書: Goアプリ開発に役立ちそうな基礎知識 | フューチャー技術ブログ

                                                    はじめにTIG真野です。育休明けです。 フューチャー社内のタスクランナーはmakeやTaskなど複数の流派があり、チームによって使い分けられています。個人的にはmakeで良いんじゃないかと思っていますが、Taskも良いですよね。 makeは細かい記法をいつも忘れる+調べるとC言語向けの情報が出てきて脳内変換に手間を感じたため、makeを用いてWebバックエンドアプリをGoで開発するということをテーマに、役立ちそうな情報をまとめます。 なお、今記事におけるmakeは、GNU Makeを指します。バージョンは以下で動かしています。 MakefileのためのEditorConfigMakefileのインデントはハードタブである必要があります。誤りを防ぐためにもEditorConfigを設定しておくと良いでしょう。 makeは通常、Makefileという名称をデフォルトで認識しますが、同一フォルダ

                                                      Makefile覚書: Goアプリ開発に役立ちそうな基礎知識 | フューチャー技術ブログ
                                                    • freeeの自動テストの全体構成 - freee Developers Hub

                                                      こんにちは、Software Engineer in Qualityチーム(通称SEQチーム)の @teyamagu です。 私たちのチームは普段自動/手動テストの基盤開発や開発フィードバックサイクルの高速化に向けた開発をおこなっています。 その一環で、先日、社内でfreeeの自動テストシステム全体像を共有したのですが、この辺りのことを社外の友人達と話したところ、自動テストの具体的な構成や普段の運用など事例が少なく、どんなことをやっているのかイメージしにくいとの話を伺ったので、社内向け原稿をちょっと手直しして、おすそ分けと言うことで、ここで紹介します。 特に変わったことをおこなっているわけではありませんが、自動テストの関係性の理解に参考になれば幸いです。 基本的な考え方 自動テストが既存のデプロイ・リリースのブロッカーではなく、開発のフィードバックを加速させるために、自動テストそのものが高

                                                        freeeの自動テストの全体構成 - freee Developers Hub
                                                      • 共同開発を始めるときに便利な 5 つの GitHub Actions

                                                        はじめに スタートアップ等において新しいプロダクトを始める時は、負債が無い代わりに何もありません。 そういった時に、ソフトウェアの品質を担保するための CI のセットアップが、初期から重要になってきます。 GitHub を使用している場合は、GitHub Actions を使用されることが殆どだと思うので、そちらを前提に進めていきたいと思います。 1. rhysd/actionlint 様々なエンジニアが action を追加したり、編集したりするようになった時、全員が正しい書き方で書いていくことは難しいです。 また、それを 1 人の GitHub Actions Expert がレビューしていくのは大変で、属人化してしまっているので、避ける方が望ましいです。 以下をコピペすれば、使用できます。 name: Actionlint on: push: branches: [ main ] p

                                                          共同開発を始めるときに便利な 5 つの GitHub Actions
                                                        • GitHub ActionsでDocker Buildするときのキャッシュテクニック - cockscomblog?

                                                          GitHub Actionsでdocker buildすることが多い。このときのキャッシュをどうするかという話題。 基本 GitHub Actionsでdocker buildしてAmazon ECRにdocker pushする、典型的な.github/workflow/docker-push-to-ecr.ymlはこういう感じ。 name: Push to Amazon ECR on: push: branches: [ 'main' ] jobs: docker: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - uses: docker/setup-buildx-action@v1 - name: Configure AWS credentials uses: aws-actions/configure-aws-c

                                                            GitHub ActionsでDocker Buildするときのキャッシュテクニック - cockscomblog?
                                                          • エンジニア全員が Terraform を安心・安全に触れるような仕組みを整えています - VisasQ Dev Blog

                                                            はじめに こんにちは!DPE(Developer Productivity Engineering)チームの高畑です。 ちょっと前に iPhone 15 Pro に変えてようやく USB-C ケーブルに統一できる!と思っていたら、手元にある Magic Trackpad が Lightning ケーブルでしょんぼりしました。 さて今回は、ビザスクのインフラ周りで利用している Terraform をエンジニア全員が安心・安全に利用できる仕組みづくりを行なっている話をしていきます! これまで ビザスクではインフラの構築・運用に Terraform を利用しており、依頼ベースで DPE のメンバーが Terraform の修正を行なってレビュー&リリースをしていました。 開発メンバーから Terraform の PR をあげてもらうこともありますが、plan / apply の権限を持っていない

                                                              エンジニア全員が Terraform を安心・安全に触れるような仕組みを整えています - VisasQ Dev Blog
                                                            • サーバレス時代の負荷テスト戦略 〜CircleCIで実現する継続的負荷テストとチューニングTips〜 - Qiita

                                                              負荷テストとサーバレス 負荷テストに対する考え方は時代とともに変化してきました。従来はサーバスペックやシステムの限界性能を測るという考え方でしたが、クラウドネイティブなシステムではそれに加えて、システムの弾力性(スケールアウトのしやすさ)も考慮する必要があります。 本記事では、負荷テストによるシステムの弾力性の評価と、改善する方法についてツールの具体的な使用方法やアプリケーションのチューニング Tips を交えて説明します。システムの弾力性を評価するために、プロダクション環境でのユーザからのリクエストを想定したロードテストを検討します。 ロードテストでは以下の項目を検証します。 ドリップテスト ドリップテストは通常、数日間にわたって行われます。通常のバックグラウンド負荷レベルをシミュレートします。遅延またはエラー率の増加が見られる処理を特定します。 スラムテスト スラムテストは、トラフィッ

                                                                サーバレス時代の負荷テスト戦略 〜CircleCIで実現する継続的負荷テストとチューニングTips〜 - Qiita
                                                              • 7年在籍したCircleCIを退職しました

                                                                このエントリーについて いやゆる退職ブログです。どのようにしてCircleCIに入り、どんな仕事をし、そしてなぜやめるのかについて書いています。あとちょっぴり求人要素も入っています。 アメリカのスタートアップで働くのってどう?英語はどれくらい必要?など、実体験に基づいた一般論も書きました。海外のスタートアップに挑戦しようとしている方の後押しになれば幸いです。 目次 コンパクトにするつもりが、書きたいことが沢山ありすぎて長文となってしまいました。前半は思い出の振り返りポエムなので、興味がない方は海外のスタートアップで働くことについてまでスキップしてもらって大丈夫です。 CircleCIについて CircleCIでやったこと ソフトウェア開発 日本法人の立ち上げ SRE 海外のスタートアップで働くことについて 時差について フルリモートについて ストックオプションについて CircleCIで働

                                                                • 「まともに単体テストを書ける人は実はすごく少ない」 市場バグを発生させない“単体テストで対処する”という考え方

                                                                  品質やテストといった活動が「本質的にアジャイルになって変わらなければならない」といった問題を定義し、その解決手段を提案する「今、全エンジニアに求められる『アジャイル開発での品質視点の変化』」。ここで株式会社デジタルハーツホールディングスの高橋氏が登壇。最後に、あらためて参加者からの質問に回答します。前回はこちらから。 どうすればうまくリファクタリングができるか 高橋寿一氏(以下、高橋):じゃあここでもう1回Q&Aタイムを取ります。 高木陽平氏(以下、高木):ありがとうございます。今Q&Aにまだ質問が上がっていないみたいなので、ちょっと私から質問します。リファクタリングをしなければいけないところって、逆に手をつけられないようなけっこう複雑怪奇な部分だと思うんです。そこらへんはどうすればうまくリファクタリングができるんでしょうっていう(笑)。 高橋:まず、日本人がすごくリファクタリングが嫌いな

                                                                    「まともに単体テストを書ける人は実はすごく少ない」 市場バグを発生させない“単体テストで対処する”という考え方
                                                                  • Webサービスを1日10回デプロイするための取り組み / SRE NEXT 2020

                                                                    CEL(Common Expression Language)で書いた条件にマッチしたIAM Policyを見つける / iam-policy-finder

                                                                      Webサービスを1日10回デプロイするための取り組み / SRE NEXT 2020
                                                                    • GitHub Actions のワークフローをチェックする actionlint をつくった - はやくプログラムになりたい

                                                                      GitHub Actions のワークフローを静的にチェックする actionlint というコマンドラインツールを最近つくっていて,概ね欲しい機能が揃って実装も安定してきたので紹介します. github.com なぜワークフローファイルの lint をすべきなのか GitHub Actions が正式リリースされてからだいぶ経ち,GitHub 上での CI は GitHub Actions が第一候補となってきているように感じます.僕も新規にリポジトリを作成して CI をセットアップする場合はほぼ GitHub Actions を使っています. ですが,GitHub Actions には下記のような問題があり,actionlint でそれらを解決・緩和したいというのが理由です. ワークフローを実装する時は,GitHub に push して CI が実行されるのを待って結果を確認するという

                                                                        GitHub Actions のワークフローをチェックする actionlint をつくった - はやくプログラムになりたい
                                                                      • テストでのデータベース単位の捉えかた - 日々常々

                                                                        データベース(に限らずあらゆる永続化リソース)を使用するテストをいかにして行うかはいつだって悩みの種です。この悩みは「どうやったらデータベースを使用するテストを行えるかわからない」ではなく「なんとかやってるけど、不満のようなものがある」というものになるかと思います。 やりかたはたくさんあるのですが、その優劣は条件なしに比較する意味がないくらい、条件に依存します。どんな選択肢も「この条件なら最適」と言えてしまうだけに、広いコンテキストで「こうするのがベスト」とも言いづらいのです。 前提 xUnit Test Patterns を下敷きにします。 ユニットテストでの話です。他でもある程度通じます。 具象イメージはSpringBootを使用するWebアプリケーションです。そこまでべったりな内容ではありませんが、背景にあるとご理解ください。他でもそれなりに通じます。 データベースを使用するテストで

                                                                          テストでのデータベース単位の捉えかた - 日々常々
                                                                        • トランクベース開発とデプロイ - Mitsuyuki.Shiiba

                                                                          前回は Git-flow とデプロイについて書いたので bufferings.hatenablog.com 今回は、トランクベース開発とデプロイについて考える。LinkedIn, Facebook, Google などもトランクベースの開発をしてるんだね 参照: Agility Requires Safety | Y Combinator トランクベース開発は Git じゃなくてもいいと思うんだけど、この記事では Git 前提で考える トランクベース開発? 幹(trunk)となるブランチにみんなが小さな変更を加えていくブランチモデル。寿命の長いブランチを作らないようにすることで、マージでつらい思いをしなくて済むようになって、ビルドも壊れないようにできて、ヤッター!というもの trunkbaseddevelopment.com Git-flow みたいに develop ブランチで開発をする

                                                                            トランクベース開発とデプロイ - Mitsuyuki.Shiiba
                                                                          • GitHub Actions のデバッグをローカルで行う

                                                                            概要 GitHub Actions で GitHub ホストランナーを使用する場合、パブリックポジトリは無料ですがプライベートリポジトリは従量課金(無料枠あり)です。 ワークフローを編集する際にデバッグしていると結構な時間を消費してしまいます。 そこでデバッグ時は GitHub ホストランナーを使わずに無料で実行する方法を 3 種類紹介します。 nektos/act 言わずと知れたローカル実行ツールです。 すべてを再現することはできませんがコミットを増やさずにデバッグができます。 注意点 ubuntu-* のみサポート ソフトウェアは指定する Docker イメージ依存、デフォルトのイメージだと色々足りないので -P で指定 secrets.GITHUB_TOKEN が未定義なので Personal Access Token を発行し設定が必要 サービスコンテナ services が使えな

                                                                              GitHub Actions のデバッグをローカルで行う
                                                                            • GitHub Actionsのワークフローを可視化するactions-timelineを作った

                                                                              最初に作ったのがCIAnalyzerです。なるべくツール自体の運用の手間がかからないように常駐サーバー無し、データの保存先と可視化はマネージドサービスを使う前提で設計しました。具体的にはデータの保存先をBigQueryとすることによって自前でDBを管理する必要をなくし、webhookを受けるのではなくcronで定期的にAPIを叩くことで常駐サーバーを不要にし、データの可視化はBigQueryと簡単に連携できてマネージドサービスであるLooker Studioを使用する前提としました。 CIAnalyzerのアーキテクチャ CIAnalyzerを作ったきっかけはAzure Pipelineの分析機能に感銘を受けたことで、それと同等の分析を当時自分が業務とプライベートで使用していたJenkins, CircleCI, Bitrise, GitHub Actionsでも可能にしたいと思って開発を

                                                                                GitHub Actionsのワークフローを可視化するactions-timelineを作った
                                                                              • CircleCIへの不正アクセスについてまとめてみた - piyolog

                                                                                2023年1月4日、CircleCIはセキュリティインシデントが発生したことを公表し、利用者へ注意を呼びかけました。また1月13日には侵入経路を含む調査結果などをまとめたインシデントレポートを公表しました。ここでは関連する情報をまとめます。 CircleCIより流出したデータから利用者のサードパーティシステムに影響 CircleCIが不正アクセスを受け、同社のプラットフォーム上に保存された利用者のサードパーティシステム(Githubなど)の環境変数、キー、トークンを含む情報の一部が流出した。不正アクセスにより情報が流出したのはクラウドで提供されるCircleCIで、オンプレミス型のCircleCI Serverは影響を受けない。 2023年1月13日公表時点で本件の影響を受け、利用者よりサードパーティシステムへの不正アクセスが生じたと報告を受けたケースは5件未満。但しCircleCIは不正

                                                                                  CircleCIへの不正アクセスについてまとめてみた - piyolog
                                                                                • 僕も41歳だー。CircleCI に入社しました。 - Mitsuyuki.Shiiba

                                                                                  そんむーさんのこの記事を読んで、すごいなぁかっこいいなぁって思って、そういえば僕も41歳だーって思ったので、書くことにした。軽い気持ちで書き始めたら思っていたよりもとても考え込んでしまった。 songmu.jp CircleCI に入社しました 11年勤めた楽天を離れて CircleCI に入社しました。先週の月曜日の10月18日から Senior Full Stack Engineer として仕事をしてます。大阪の自宅からフルリモートです。 寒くなってきたからちょうど良かったー! https://t.co/td9lks2qVS pic.twitter.com/9AW6X8CPgH— Mitsuyuki Shiiba (@bufferings) October 20, 2021 次の挑戦をするのに、ちょうどいい時期かなぁ ここ数年は、色んなチームのサポートをするエンジニアをやってました。テ

                                                                                    僕も41歳だー。CircleCI に入社しました。 - Mitsuyuki.Shiiba

                                                                                  新着記事