タグ

ブックマーク / mitomasan.hatenablog.com (5)

  • 同じビルドやテストを何度も実行しない方法 - コンポツさん

    GitHub Actions で同じビルドやテストを何度も実行しない方法を紹介します。 ホストランナーを ubuntu-linux にした場合、実行する必要のないジョブは 10 秒程度でスキップ可能です。 注意 この記事は自作の OSS ツール sver および私が現在所属するサイボウス社の グローバル向けAWSkintone開発チーム の宣伝が含まれます。 Summary ビルドやテストといった CI のジョブに再現性がある場合は複数回実行しても意味がない ジョブが依存する環境やソースコードを元にハッシュ値を計算することで同等なジョブに一意なラベルをつけられる ジョブ実行後に実行済みラベルを artifact として保存しておくことで後続の同等なジョブをスキップできる 効果 最初に効果を示します。 sver というプロジェクトのジョブの実行結果です。 これは通常時のジョブの実行時間です

    同じビルドやテストを何度も実行しない方法 - コンポツさん
    teppeis
    teppeis 2022/07/15
    monorepoでCIジョブが依存するファイルリストのハッシュを取って重複ジョブを抑制するツールsverの紹介。bazelを参考に作ったサイボウズ社内用ツールをベースにOSS化したもの
  • リモートワーク、ひとりでやるか、みんなでやるか - コンポツさん

    前置き 自分はいま週に3日の在宅勤務、2日はオフィスに出社という働き方を3年程度続けている。 このペース自体は3年間ほとんど変わっていないのだが、2018年1月からチームとしての仕事のやり方が大きく変わった。 具体的にはチームでモブプログラミングと1週間スプリントを始めた。 10年以上プログラマーとしてやってきているが、プログラマーとはこういう働き方をするものだっただろうかという新鮮な気持ちがある。 つまり、ブログタイトルのひとりでやるか、みんなでやるかとは、リモートワークをしながらその業務は個人で非同期的にやるのか、複数人で同期的にやるのかという意味である。 今までのやり方と今のやり方、どちらが良い悪いというものではないが、とにかく今自分はどう感じているかというメモを残しておくことにする。 所感 3人よれば文殊の知恵という言葉は正しい。2人(ペア)と3人(モブ)ではかなり違う。 リモート

    リモートワーク、ひとりでやるか、みんなでやるか - コンポツさん
    teppeis
    teppeis 2018/06/03
    弊社モブ+リモートの知見です。
  • マルチテナントアーキテクチャについて - コンポツさん

    SaaSシステムを開発しているみなさま、お元気でしょうか。 SaaSシステムというといわゆるWebサービスよりももう少しBtoBの雰囲気が漂ってまいります。 SaaSシステムでは契約者(ここではテナントと呼ぶ)が複数いて、テナント毎に複数のログインユーザーやロールが存在するのが一般的です。そして当然ながらテナント毎のデータは漏洩・混濁が許されない高いセキュリティが求められます。 SaaSシステムの構築はスケーラビリティにおいても100テナント程度から始まりゆくゆくは数千、数万テナントまで少なくとも線形にスケールするアーキテクチャを開発当初から求められ、さらに突発的な大規模テナントも問題なく吸収したいという要求があります。 その要求を満たす設計・開発・保守・運用をやっていくのは当然ながら簡単ではありません。 というわけで今日はマルチテナントアーキテクチャのお話です。 世に出る情報がとっても少

    マルチテナントアーキテクチャについて - コンポツさん
  • 続・Web系の自分が想像と障害で学んだバッチ処理・設計の基本 - コンポツさん

    バッチ処理というのがそれ単体で勉強するのが難しく勉強しようとすると何に手を付けるべきかさっぱりわからないということは、先日のブログで述べたとおり。 自分が経験の中で得てきた知見は正しいのかどうか、世間の人に見てもらいたかったというのが書いた動機。 そして、新たな視点や指摘をゲットしてより不測の事態を考慮できている最高なバッチを作りたいという目的があったわけだ。 で、いろいろな意見をもらったのだけどその中で特に辛いと感じたのはこれ。 基幹システムにおけるバッチ処理みたいなものに関する知見については、カジュアルに学ぶ方法はありません。それを体系化した知識として整理した上で、実装できる組織があるんなら、それでメシがえるんじゃないですかね。— 太一 (@ryushi) 2016, 2月 18 読んでいると 「俺達は障害でつらい思いをしてるし当然先人達も障害でつらい思いをしているはずだ。 なのに、

    続・Web系の自分が想像と障害で学んだバッチ処理・設計の基本 - コンポツさん
    teppeis
    teppeis 2016/02/19
    突然のボス登場でウィルキンソン吹いた
  • Web系の自分が想像と障害で学んだバッチ処理・設計の基本 - コンポツさん

    バッチ処理というのはそれ単体で勉強しようとするとなかなか何を勉強したらいいのかわからないことが多い。 特に経験がWeb系ばっかりだと、いざバッチ処理を実装しようとした時に基的なノウハウを知らないままに書いてしまうことが多い。 バッチ処理というのは実態を整理すると「何らかのトリガーを期に起動し、データをロード・加工・変換・集計してから、出力する」という事になる。 まぁ、INがあって処理してOUTがあるという点では関数だと考えてもいいだろう。 システムの利用者(人に限らない)のアクションとは直接関係ない処理であったり、利用者のアクションをトリガーとしていても、即時にレスポンスがいらないor返せない場合に バッチ処理を選択する事が多い。 実現方式はシェルスクリプト、LL言語、実行可能バイナリだったりするし、デーモンとして立ち上げる場合もある。 利用者の操作に対して対話的・同期的な処理はオンライ

    Web系の自分が想像と障害で学んだバッチ処理・設計の基本 - コンポツさん
    teppeis
    teppeis 2016/02/18
    現場の知見だ
  • 1