LINE Serverの開発とリリースプロセス « LINE Engineers' Blog
皆さんお元気ですか?LINEサーバー開発室でサーバ開発を担当している崔珉秀と申します。 この記事ではLINEのサーバーの開発とリリースプロセスについて述べたいと思います。 LINEの開発者はどんな形で開発しているのか、サービスに変更事項をどのように適用しているのか、お互い協力してより良い開発環境を得るためにどんな努力をしているのかをお伝えする機会になったらいいなと思います。 ここで述べるリリースプロセスは、LINEのサーバ開発の流れとソース管理システムの運用方法、そして本番環境に変更事項を適用するまでの過程です。 LINEのServer Applicationはその役割とシステムの構成によって複数のServer Applicationに分かれて構成されています。 例えばNetwork通信及びProtocolなどを担当するApplication、messagingやsocial graph
VOYAGE GROUP エンジニアブログ : Gitブランチによるサーバ管理
2012年09月27日10:14 カテゴリ Gitブランチによるサーバ管理 はじめまして。株式会社adingoのこんどう（@_zoo）と申します。今年の4月から新しいチームに配属され、チームのバージョン管理やリリースプロセスの整備をやっています。 今回の記事ではリリースプロセスの課題解決について、チームで取り組んだ時に出てきたGitブランチの活用方法についてご紹介させていただきます。 * 広告サービスの事例 まず、簡略ですが環境毎のサーバ構成をご紹介します。DBやその他諸々のサーバも省略し、Webサーバとビルドサーバのみ記載しています。 システム的な構成の紹介はざっくりこれだけにしておきます。 システム構成図ではサーバ台数は一台ですがサーバが数十台に増えた時のことも考えました。 1台2台のうちはいいけれど、台数が増えてくると各サーバの状態を確認という声もありました。 数十台のサーバを運用し
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
このドメインは お名前.com から取得されました。 お名前.com は GMOインターネットグループ(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。 ※1 「国内シェア」は、ICANN(インターネットのドメイン名などの資源を管理する非営利団体)の公表数値をもとに集計。gTLDが集計の対象。 日本のドメイン登録業者(レジストラ)（「ICANNがレジストラとして認定した企業」一覧（InterNIC提供）内に「Japan」の記載があるもの）を対象。 レジストラ「GMO Internet Group, Inc. d/b/a Onamae.com」のシェア値を集計。 2024年5月時点の調査。
「Pull Request」 はオープンソースに限らず使える優れた開発フローだ - 肉とビールとパンケーキ by @sotarok
チーム開発において、「チケット/Issue」「TDD」「コードレビュー」など、ソースコードの変更に対する効果的な開発フローについてよく考えるのだけど、なんにしてもこのあたりは非常に課題が多く、各社各コミュニティで色々なやり方が模索されているポイントだと思う。 で、まぁご多分に漏れず僕もよく考えるわけだけど、現状その過程で Pull Request こそが非常に効果的なのではないか、と思うので、ちょっとまとめてみようかと思う。 もちろん、言うまでもないようなことだよ、という人もいるかもしれないけど、そういう人がたくさんいると、非常に喜ばしいことだね。 Pull Request とは GitHub でこう呼ばれているので、こう呼ぶことにするが、ここでは、複数のリポジトリ/ブランチ間でのオープンな patch のやりとりのことだと考える。 あと、自分が使っているのが Git なので、ここでは G
Backup your Database in Git | Viget Extend
Short version: dump your production database into a git repository for an instant backup solution. Long version: keeping backups of production data is fundamental for a well-run web application, but it’s tricky to maintain history while keeping disk usage at a reasonable level. You could continually overwrite the backup with the latest data, but you risk automatically replacing good data with bad.
継続開発のススメ - Twisted Mind
概要 開発をすればリリースがあり、リリースが終われば開発があります。継続開発をする以上はリリースと開発の繰り返しです。 開発手法やリリース手段は沢山あるのですが、あまりしっくりくるものが無かったので自分でまとめてみました。 これで完璧というものは残念ながらこの世にないと思うので、これからも臨機応変に良い流れを作って行ければと思います。 この文章は以下のような構成になってます。書き殴りですみません。 バージョンの付け方 ソースコード管理とリリース タスク駆動 環境方針 定義 いくつか事前に定義しておかないと話しが訳わからなくなりそうなので。 バージョン管理には git を採用しています。 開発というのはコードを書く事だけを指してはいません。 ここでいうフレームワークは「自身で開発している」として扱います。そうしないとちょっと難しいので。 ライブラリは自身の開発とそれ以外があると思いますので、
gitとRedmineと連携させるgitサブコマンド: git-ticket - みずぴー日記
git + Redmineで開発する場合、Redmineのチケットごとにトピックブランチを切ることが多いですが、ちょいちょいチケットの内容を忘れてしまいます。 そういうときに、いちいちブラウザでチケットを見にいくのがダルいので、チケットのサマリを表示するgitのサブコマンドを作りました。 なお、本コマンドはbleis-hooksと併用することを想定しています。 インストール方法 git ticket subcommand · GitHub からダウンロードし、パスの通ったディレクトリに配置してください。 $ wget https://raw.github.com/gist/014371584dbf85d053ed/f8ade6f7fc36a4c8f49f72a538a6322bfb726bf8/git-ticket $ mv git-ticket /path/to/some/dir $ c
コミットについて語ってみる - wyukawa's diary
途中から難しくなってきてとばし読み気味になったが実用Gitはすばらしい本だ。 入門Gitもすばらしかったがそれにも劣らない（この２冊ほどでは無いかもしれないが入門gitもいい本だ）。 読んでいて感じたのはGitは歴史を書き換えてでもいいコミットを作ることに関心を持っているように思う。 間違えたコミットコメントを修正したいと思うことは誰でもありそうだが、それだけではなくコミットをまとめたり、順番を変えたりすることもGitではできる。さながら歴史をリアルタイムで作り替えているようだ。 そうやって作られたある意味では完璧なコミット履歴を見てみたい気もする。 コミットについて語る場合２つのパースペクティブがある。１つは粒度でもう１つはコメントだ。 コミットの粒度は論理的にまとまった単位であるべきだ。例えば１つのバグ修正で３ファイルいじったなら１コミットであるべきでファイル毎に３回コミットされたら後
Island Life - gitのワークフロー
About 南の島のプログラマ。 たまに役者。 Practical Schemeの主。 WiLiKi:Shiro 最近のエントリ 米国の大学進学無限cxr高校受験Defense振り返ってみると2019年は色々学んで楽...覚えるより忘れる方が難しい(こともある)眼鏡のつると3DプリンタIris Klein Acting ClassSAG-AFTRA conservatory: Voice Acting創作活動って自分を晒け出さねばならないと...More... 最近のコメント shiro on 歳を取ると時間が速く過ぎるのは、新しいことに挑戦しないから? (2023/03/14)1357 on 歳を取ると時間が速く過ぎるのは、新しいことに挑戦しないから? (2023/03/01)ベアトリーチェ on ハイポハイポハイポのシューリンガン (2022/04/02)ベアトリーチェ on ハイポハ
TDD と Git についてメモ - ぐるぐる～
ついったーにつぶやいたものを中心にまとめました。 まだこれで正しいという確信を持てていないので、メモという位置付けでお願いします*1。 なので追記する可能性が高いです。 TDD でドキュメンテーションコメントを書くタイミング カテゴリを指定して実行するテストを分ける git stash の使い道 TDD でドキュメンテーションコメントを書くタイミング ここでは Git を前提にしますけど、rebase 使えるならほかのものでも大丈夫なはずです。 TDD でいつドキュメンテーションコメントを書けばいいのか、というのは、 Re:TDD を理解するためのまとめ - ぐるぐる〜 TDD Boot Camp の参加報告とか読んで - ぐるぐる〜 と、過去 (といっても半年も経ってないけど) ずっともやもやしてたんですが、 事前条件で楽できないかなーという考え - Logic Dice に対する自分な
Google製のGit用ソースコードレビューシステム·Gerrit MOONGIFT
ソースコードのレビューはシステムの品質を高めるのに大切な作業だ。GoogleやVMWareでも使われており、ブラウザを使って差分を確認してコメントができるようになっている。社内向けには拙作のSubversionソースコードレビューシステムの宍道湖がある（Rails製）。 Git向けソースコードレビューシステム この手のツールはSubversion向けのものが多かったが、Gitでも使いたいならGerritに挑戦してみよう。 今回紹介するオープンソース・ソフトウェアはGerrit、Git向けソースコードレビューシステムだ。 GerritはGoogleが大々的に発表している訳ではないが、Google社員が開発しておりAndroidのオープンソースプロジェクトにおけるソースコードレビューにも利用されている。他のシステム同様に差分を見て、そこにコメントすることが可能だ。 差分を見てコメントする 差分
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
