リリース頻度を毎週から毎日にしてみた - NTT Communications Engineers' Blog
目次 目次 はじめに NeWork とは リリース頻度変更の背景 それまでの運用 課題 実現方法 解説 日次でワークフローが起動するようにする main ブランチの HEAD にタグが付与されていなければ付与する develop に差分があれば main へのマージを自動で行う 細かな工夫点 main の内容を develop に自動で取り込む 祝日はリリースしないようにする 自動リリース・自動 develop → main マージの制御 Slack にリリース結果を通知する stg 環境に変更内容を通知する その他の考慮 上司への事前説明の省略 スプリントレビュー前のリリース リリースノート 品質面 リリース頻度を変えてみて おわりに はじめに こんにちは、NeWork 開発チームの藤野です。普段はオンラインワークスペースサービス NeWork のエンジニアリングマネジメントをしています
決して止まらないカイゼン体制を作りたい | 深津 貴之 (fladdict) | note
中長期のための大きなデザインも大事だけど、そのために日々の改修が犠牲になってはならない（その逆は言語道断）。そんなわけで、しばらくの間は、1〜2日で終わる小さな改修を、コンスタントにnoteチームに提案したいなぁと考えている。 もちろん、「リソースが許せば」だけれども。なぜならpiece of cakeにはまだデザイナーが1人しかいないことだ。そんなわけで、中長期でどういうチームを作るべきかウンウン唸っている。 並行して走るスロットが3-4つ欲しい理想を言えば、デザイン/開発リソースを3つのグループにわけたい。「大局リソース」、「開発リソース」、「カイゼンリソース」の3つだ。これらはそれぞれ独立しているのが望ましい。複数のレイヤーを1人のスタッフが兼任していると、どれかが忙しくなると、他の全てがストップしてしまうからだ。 大局リソース ガイドライン、コンポーネントなど、会社全体にストックさ
はてなブログのデプロイを約6倍高速化したはなし - Sexually Knowing
今年、稼働中のサービスであるはてなブログのデプロイ方法を新しい方式へ無事故で移行し、従来と比べて約6倍速くデプロイできるようになりました。 この記事では、安全にデプロイ方式を変えたプロセスを順を追って紹介します。 はてなブログと継続的デリバリー デプロイが遅い 複雑なデプロイ設定 デプロイのテストを書く ボトルネックの発見、そして pull 型から push 型のデプロイへ 新デプロイへの移行 結果 まとめ はてなブログと継続的デリバリー はてなブログは1日あたり平均して1.02回デプロイを行っています。これは土日を除いた週5日の営業日に対する平均です。ざっくりとした算出で、祝日は考慮していません。5月と9月の祝日を含めるともう少し多くなるかもしれません。 また、原則として休日の前日にはデプロイしないことになっています。もしもデプロイした変更にバグがあった場合、休日が明けてから対応するか、
ゲーム
みなさんこんにちは。GREE Advent Calendar 2015、24日目は消滅都市というスマートフォン向けゲームのメインプログラマを担当しております、渡部晋司がお送りいたします。クリスマスイヴではありますが、私は(すでに既婚者なので)恋愛云々のドキドキ感もなければ夫婦間でプレゼント交換もすることもなく、目下楽しみと言えば大きなチキンを食べることぐらい。食欲って怖いですね。 さてさて、今年もあと少しで終わってしまいます。お読みになっている皆様は、今年一年どんな一年だったでしょうか？ 私の方は消滅都市の運用を年初から年末までやっておりまして、それ以外のことは何もやってないといった感じでした。 本エントリはAdvent Calendarとしての記事ですから、本当は技術的な話とか How To 的なお話ができればよかったのですが、実は今年はCocos2d-x talks #2、CEDEC
大人のスタートアップは大人のリリースができる。そう、ChatOpsならね。 | メルカリエンジニアリング
このブログをご覧のみなさま初めまして。@siroken3です。メルカリではインフラチームに所属しており、リリースの仕組み構築を担当しています。 メルカリのリリースについて メルカリではカスタマーサポートから受け取る改善要望、プロダクトとしてまだやれてないことなど多くのタスクがあり現在も継続して開発とリリースが行われています。 Issue管理はRedmine、ソースコードのリポジトリはGitHub privateを使用しています。Pull Request(以下PR)でのコードレビューを実施、masterブランチへマージされたものをリリースするのが基本的なフローです。 一方、1年前まではリリース頻度は週1回のリリース日を決めて実施していましたが、この1年で大きく変わりました。現在では日本版とUS版を合わせて10回〜30回/日の頻度でリリースしています。この記事では大きく変わったメルカリのリリー
安全なリリースのために心がけていること - クックパッド開発者ブログ
こんにちは。会員事業部の高田です。今回は安全にリリースをするために、アプリケーションエンジニアとして心がけていることについて書きます。 クックパッドではなるべく早くユーザーに価値を届けることを大切にしているため、1 日に何度も安全にリリースできるしくみや、リリース後に発生したエラーにすぐに気付けるしくみがあります。しかし、アプリケーションレイヤーの問題はアプリケーションエンジニアが気をつけなければいけません。私個人としては、少し気をつければ防げた問題を起こしてユーザーや会社に迷惑をかけてしまった経験があるため、注意深くなっています。 プロジェクトの大きさや目的はさまざまあり、早くリリースして検証したい施策などもあると思います。今回は慎重にリリースしたいプロジェクトの例として、有料会員の解約の前に特定のユーザーにのみクーポンを配布するという架空のプロジェクトを元にお話します。 1. 準備 リ
『flynnを使ったオートスケーリングシステム』
さて、今回の記事のネタは「flynnというオープンソースを使ってオートスケーリングシステムを構築してみた」というお話です。
GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー
少し前までアプリケーションのデプロイと言えば capistrano などをコマンドラインから叩いてデプロイ、みたいなことをやっていたが、最近は少し様子が違うのでそのやり方、KAIZEN platform Inc. での事例を紹介する。 GitHub のイベントを契機に CI as a Service にデプロイを担当させる GitHub で Pull Request を送って開発するのが前提になっているのは以前にも紹介した。 最近は Travis CI や CircleCI などに代表される CI (Continuous Integration) as a Service があって、CI も自分たちで環境を構築しなくてもクラウドに任せることができる。KAIZEN では CircleCI を積極的に使っている。 これらの CI as a Service は基本的に GitHub と連携するこ
5分で分かるデプロイ自動化への道
12月20日に第1回ワンクリックデプロイ勉強会で、デプロイの自動化について好き勝手に喋ったりデモしたりする予定なのですが、当日話す内容の概略について以下に載せておきます。 以下にあげることをやっておけばデプロイ自動化、ワンクリックデプロイはそんなに遠くないところにあると思います。 ソースコードのバージョン管理いわずもがな。全ての起点はここにあるコードの共同所有の原則への理解このソースコードは本番環境または開発環境などで同じように動作しなければならないテストを書く習慣、コミット前に他のテストも含めて通してからコミットする習慣設定ファイルのバージョン管理環境によって異なる設定値（接続先データベース情報など）が書かれた設定ファイルもバージョン管理する開発環境用、ステージング環境用、本番環境用などに分けて定義し、容易に切り替え可能にする本番環境に配置する際に、アプリケーションの各所を書き換えなけれ
今日から始めるサーバ構築の省力化 - GeekFactory
SSHクライアントたくさん並べてペーストしまくるのが許されるのは小学生までだよね と言ってみたかっただけです。こんにちは。 Capistranoでサーバ構築を省力化する方法を紹介します。サーバ構築の自動化といえばChefやPuppetが有名ですが、CapistranoはサーバにSSH接続さえできれば利用できるメリットがあります。データセンタに持ち込むノートPCにCapistranoを仕込んでおけば便利なツールになるし、短期間に検証用のサーバを構築する場合も有用なツールになるでしょう。Capistranoはデプロイツールとして使われることが多いですが、サーバ構築にも有用です。 CapistranoはRubyで書かれたツールで、複数のサーバにSSH接続してコマンドを実行できます。同様のツールとしてexpectがありますが、CapistranoのスクリプトはRubyの内部DSLなので書きやすく拡
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
hudson: an extensible continuous integration engine