なんか急に給料が1.4倍になった
4人部署で１人産休からの時短、１人が夏の間に退職で実質稼働人員が2.3人になった。 当然ながら仕事量は変わらない、そして新規で人が入るのは年度が変わってから。 そんで働く女性応援ってことで何故か時短してマネジメントもなんもできてない時短ママが昇進＆昇給。 それに伴い流石にということで別部署から１人補充が入った。 まあここまでは良かった、別に文句はない。 問題はその時短ママがなんでか知らんがなんのマネジメントもできない、しない上に今までやってた仕事を管理業務が増えたからしない、できないと言って新人教育も俺等に投げてきた事。 そんで時短ママは発熱でしょっちゅう帰るしslackにも応答ない事が増えた。 勘違いしないでほしいが別に時短ママが帰る事も昇進した事にも文句はない。 ３人の中で一番勤務年数も長いしね。 新人教育投げてきた時はこいつマジか？って思ったけど。 ただ困ったのが俺とAさんで実質４人
ついに最強のCI/CDが完成した 〜巨大リポジトリで各チームが独立して・安全に・高速にリリースする〜 - ZOZO TECH BLOG
こんにちは。SRE部の巣立（@ksudate）です。 我々のチームでは、AWS上で多数のマイクロサービスを構築・運用しています。マイクロサービスが増えるにつれて、CI/CDの長期化やリリース手法の分散など様々な課題に直面しました。 本記事では、それらの課題をどのように解決したのかを紹介します。 目次 目次 はじめに CI/CDのこれまで Release PRによるリリース CI/CD実行時間の長期化 マイクロサービスごとのリリースが難しい リリーサーの制限ができない ドメイン単位の並行リリース リリース手法が分散する ブランチ間の同期が必要 パイプラインの増加 CI/CD実行時間の長期化 リリーサーを制限できない CI/CDの刷新 高速かつシンプルなCIパイプライン 変更差分を利用したCIパイプラインの実行 承認機能付きのCDパイプライン GitHub Environmentsによるリリー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
