2022年に試した開発ワークフロー関係の機能やツール - Kengo's blog
数えてみたら意外と数あったのでまとめます。 release-please Google謹製のリリース自動化ツール。monorepo対応のRelease Drafterという感じですが、リリースはDraft Releaseの安定版への昇格ではなく、PRのマージによって行います。PRでリリースするという点ではgit-pr-releaseぽいですが、ブランチは main だけでリリースブランチは無い感じ。changesetsよりはとっつきやすい印象です。 github.com 例えば↓のようなワークフローを用意すれば、モジュールごとにGitHub Releaseを作成するためのPRを自動作成できます。 初期セットアップでJSONファイルを2つ作る必要があるのが若干面倒ですが、それさえ越えてしまえば考えることは少なさそうです。 # .github/workflows/release-please.
半年デプロイ改善を継続して見えてきた「成果」 ~モノタロウのカナリアリリース導入のその後 - MonotaRO Tech Blog
※この記事は 開発生産性 Advent Calendar 2022 カレンダー2 の20日目の記事です。 前回記事の16日目は nakayamaatsushiさんの 『Findy Team+ Award 受賞の裏側~開発生産性向上の取り組みを振り返る~』でした。計測した開発指標をどのように開発生産性向上に結び付けているのか、具体的なアクション事例が紹介されており非常に参考になりました！ この記事の内容 カナリアリリースを導入しました やってみての感想 うまくいったこと デプロイ頻度が上がる 本番で発覚するバグのユーザー影響を抑えられる 試しやすくなる 期待通りじゃなかったこと 開発リードタイムが短縮される⇒それほどでもない 機能開発のスループットがあがる⇒べつに上がらない マージが分散することで、衝突が起こりづらくなる⇒ならない 本番環境での不具合は発生しなくなる⇒そうとはいいきれない わ
運用中のPostgreSQLのスキーマを無停止で安全に変更する | 株式会社ヌーラボ(Nulab inc.)
初めに こんにちは。ビジネスチャットサービスTypetalkを開発・運用している吉田です。Typetalkではデータの永続化ストレージとしてPostgreSQLを利用しています。扱うデータ量は多く、チャットというサービスの性質上書込み頻度はとても高いです。PostgreSQLを使い日々開発を進めていると、追加する機能によってはスキーマを変更する必要があります。メンテナンスを計画・告知してサービスを止めてしまえば、時間はかかるかもしれませんがスキーマの変更はそう難しくありません。しかしTypetalkはユーザーが日々の業務を進めるために利用しており、サービスが止まるとコミュニケーションが取れなくなります。業務を円滑に進めるためのビジネスチャットツールですので、極力サービスは止めたくありません（最後の計画メンテナンスは2019年6月30日で1年以上前となっています。）。本記事では以下の3つのケ
モダンアプリケーション開発ホワイトペーパー（日本語改定版）が公開されました | Amazon Web Services
Amazon Web Services ブログ モダンアプリケーション開発ホワイトペーパー（日本語改定版）が公開されました 皆さん、こんにちは！ モダンアプリケーション開発スペシャリスト ソリューションアーキテクトの福井です。 私が執筆したモダンアプリケーション開発のホワイトペーパー（日本語版）がAWSホワイトペーパーサイトで公開されましたので、その内容を紹介させて頂きます。このホワイトペーパーは、以前こちらのブログで紹介させて頂いたModern Application Development on AWS（英語版）の日本語版になります。 ホワイトペーパーの内容 公開されたホワイトペーパードキュメントは、「AWS モダンアプリケーション開発 – AWS におけるクラウドネイティブ モダンアプリケーション開発と設計パターン」（日本語版）というタイトルの51ページのドキュメントで、 はじめに
メルカリは開発組織を拡大するためにマイクロサービスアーキテクチャを採用した（後編）。Mercari Tech Conf 2018
メルカリは開発組織を拡大するためにマイクロサービスアーキテクチャを採用した（後編）。Mercari Tech Conf 2018 メルカリはこの1年、マイクロサービスアーキテクチャにどう取り組み、実現のためになにをしてきたのか。技術面と組織面の双方に関する興味深い取り組みが、10月4日に都内で行われた同社主催の技術カンファレンス「Mercari Tech Conf 2018」のセッション「Microservices Platform at Mercari」で紹介されました。 （本記事は「メルカリは開発組織を拡大するためにマイクロサービスアーキテクチャを採用した（前編）。Mercari Tech Conf 2018」の続きです） DevOps文化を組織内に醸成する 次はDevOps文化の醸成です。 この1年で、マイクロサービスの開発者が自分たちでできるようになったことが大きくふたつあります。
ブランチデプロイ環境で エンジニアが安心できる開発現場へ/branch-deploy-environment-for-engineers
2017/10/14 Productivity Engineering Vol.3 − Forkwell Meetup#5 LT Slide https://forkwell.connpass.com/event/67104/
「新機能作成時に開発ブランチに細かくmergeしていく戦略」について社内勉強会で発表しました - Hatena Developer Blog
はてなのアプリケーションエンジニアのid:shiba_yu36です。社内技術勉強会で「新機能作成時に開発ブランチに細かくmergeしていく戦略」という発表をしたので、資料を公開します。 speakerdeck.com 以下、簡単に文字でまとめておきます。 戦略 ユーザーに新機能が見えないようにする工夫をし、新機能のbranchもどんどん開発ブランチにmergeしていく mergeされたものは随時本番にリリースされるが、ユーザーに見えない工夫をしているので問題なし PRは可能な限り細かくする 機能が完成したら最後にユーザーに新機能を見えるようなPRを作り、mergeしてリリースする なぜこの戦略を使うのかいろんな失敗を経験して、この戦略を最近使っている。 失敗パターンその1: 巨大PRパターン 失敗パターンその2: 新機能リリースブランチパターン 失敗パターンその1: 巨大PRパターン 新機
Speee Cafe Meetup #07 に参加した - r7kamura - Medium
TypeScript, Flow最近会社で開発している Web アプリケーションに TypeScript を導入したという話を聞いたので、その辺に居た人を交えて、Flow と TypeScript を比較するとどういう感想ですか、という会話をした。あまり詳しくないという人向けに説明しておくと、どちらのプロジェクトも、JavaScript の文法に手を加えて静的な型検査を行えるようにしようというものである。
新規事業のグロース期を支えるエンジニアリングについて - @i2key のBlog
このブログは Recruit Engineers Advent Calendar 2016 - Adventar の12/7の記事になります。 はじめに 現在、新規事業開発部門にて、いくつかのチームの開発リーダーをしていまして、その中でチームの目標を決める中でグロースフェーズにおける開発チームの直近のやるべきことを洗い出したので、アドベントカレンダーのネタにさせていただきます。 前提として、本ポストで対象になる新規事業は下記の投稿における分類で言うと「エンジニアの書いたコード上で売上が立たないビジネスモデル」になります。そのため、エンジニアリングでKPIを向上させ売上に寄与するような一般的なグロースハッカー的な動き方についてはスコープ外です。詳しくは下記リンクをご一読ください。 i2key.hateblo.jp 現在のビジネスステージ 上記はAsh Maurya氏のRUNNING LEAN
「開発中の実装も、レビュー前からプロダクションに入れています」DeployGate導入企業インタビュー・Drivemode編
DeployGate 導入企業インタビュー Drivemode, Inc／João Orui 様 ドライバー向けに最適化されたAndroid UI(ユーザー・インタフェース)「Drivemode」を提供するDrivemode, Incは、米国カリフォルニア州・サンノゼを拠点とするスタートアップです。 「1日20回以上も最新版が配信されている」という同社の爆速な開発・改善ワークフローは一体どのように機能しているのか、 同社Director of EngineeringのJoão Orui氏にお話を伺いました。 DeployGate 導入企業インタビュー Drivemode, Inc／João Orui 様 ドライバー向けに最適化されたAndroid UI(ユーザー・インタフェース)「Drivemode」を提供するDrivemode, Incは、米国カリフォルニア州・サンノゼを拠点とするスター
Windowsと.Net環境での継続的デリバリ
"Continuous Delivery with Windows and .Net" (ダウンロード無料)はMatthew Skelton氏とChris O'Dell氏による短い本で、Jez Humble氏とDave Farley氏の"Continuous Delivery" の内容に対するWindowsと.Net環境向けの優れた補論と見ることができるだろう。 最初の章と最終章には継続的デリバリの論理的背景と組織構造へのインパクトについて書かれているものの、残りは継続的デリバリを成功させるツールの概要を説明している。 この本の主な強みはWindowsに馴染みやすいツールの学習のために必要な情報をすべて載せていることだろう。著者が指摘するように、"この本はJezとDaveの本の補遺であり、Windowsと.NETを使っているチームの継続的デリバリ導入を促進するためのものです"。2章から6章
メルカリの大規模システムを安定運用へと導いた『DevOps』とは！？ | dots. CONFERENCE SPRING 2016 | THE LANCER
大規模システムに携わるエンジニア必見！ メルカリが導入した安定運用のための技術『DevOps』というバズワードはどこかあいまいで、つかみどころがないと思っている方も多いことでしょう。運用と開発を一体化するという概念に厳密な定義はなく、どのように実務に落とし込めばよいのかが漠然としているからです。 しかし、急成長したメルカリの大規模システムを支えるSREという役割を持つエンジニア佐々木健一氏の語る奮闘から、DevOpsの本質が見えてくるのではないでしょうか。DevOpsで実現した大規模システムを安定して運用する仕組み作りをご紹介いたします。 テーマ：『メルカリDevOps物語 – 俺たちの戦いはこれからだ -』 メルカリDevOps物語 ー 俺たちの戦いはこれからだ ー メルカリはサービス開始が2013年と歴史は浅いのですが、アプリが急成長しユーザーが増えて、いろいろ困ったことがあったのでそ
一休.com におけるフロントエンド開発 // Speaker Deck
3.29 Sansan✕一休.com 勉強会での発表資料です
How We Build Code at Netflix
How does Netflix build code before it’s deployed to the cloud? While pieces of this story have been told in the past, we decided it was time we shared more details. In this post, we describe the tools and techniques used to go from source code to a deployed service serving movies and TV shows to more than 75 million global Netflix members. The above diagram expands on a previous post announcing Sp
大人のスタートアップは大人のリリースができる。そう、ChatOpsならね。 | メルカリエンジニアリング
このブログをご覧のみなさま初めまして。@siroken3です。メルカリではインフラチームに所属しており、リリースの仕組み構築を担当しています。 メルカリのリリースについて メルカリではカスタマーサポートから受け取る改善要望、プロダクトとしてまだやれてないことなど多くのタスクがあり現在も継続して開発とリリースが行われています。 Issue管理はRedmine、ソースコードのリポジトリはGitHub privateを使用しています。Pull Request(以下PR)でのコードレビューを実施、masterブランチへマージされたものをリリースするのが基本的なフローです。 一方、1年前まではリリース頻度は週1回のリリース日を決めて実施していましたが、この1年で大きく変わりました。現在では日本版とUS版を合わせて10回〜30回/日の頻度でリリースしています。この記事では大きく変わったメルカリのリリー
リリースフローを自動化して、本来の開発業務に専念できる環境を整備しよう
人はミスをしてしまうもの 開発・運用に携わる人には釈迦に説法ではありますが、どれだけ詳細なリリース手順書を整備しても、ダブルチェックのルールを設けても、天才プログラマを何人集めてもミスや失敗は付き物です。経験則からもそうですが、特に稼働が高い時（ローンチ前後）、時間がなくて焦っている時（障害時）はミス・失敗が起こりがちです。 昨今のリリース手順は簡単に思いつくだけでも、 コンパイルの実行 ユニットテストの実行 カバレッジの取得 minify,compressの実行 依存関係の解決 など、複雑化しがちです。 手作業でリリースする場合、一つ一つの作業は微々たる時間で行えても、リリースに必要な作業を積み重ねると結構な時間がかかります。また、それを継続的に行っていくとなるとかなりの時間を取ってしまいます。 これらの作業を自動化することで、機能開発・研究開発と言うエンジニア本来の業務が行える環境を整
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
git の develop ブランチは必要なのか、またはリリースtagについて
メルカリにおける、継続的なアプリケーション改善を支える技術 #retty_tech_cafe // Speaker Deck
pixivの開発フローについて話しました - catatsuyとは
クックパッドはなぜ開発しやすいのか // Speaker Deck
