ソフトウェア開発の実際login ソフトウェア開発の実際 top サービスのリリース ソースコードの管理 プロダクション・サイトの障害対応 反省会 なぜリリース頻度を上げるのか ハイレベルな指標 新機能の評価 オープンソースへの関わり (new) 今後のトピック コードレビュー エンジニアの面接 上田ガク(@gakujp)
ソースコードの管理
ソースコードの管理方法はここ10年で随分進化しました。 ソースコードの管理を行うのは、自社のすべてのエンジニアがソフトウェア開発に効率的に関われるようにするためです。そのため、以前はソースコードを管理するリポジトリがチーム単位で設置されることが多かったですが、徐々に全社で1つのリポジトリを使うような流れになってきています。 次に、リポジトリにあるコードからアプリケーションやサーバーなどを生成するための手順も各チームによってばらばらだと、せっかくコードがあっても実行して試してみることができません。そこで、ビルドを行うビルドシステムも社内で統一します。 全社的なソースコード・リポジトリの設置と、ビルドシステムの統一によって、一旦その仕組みを習得すれば、自社のエンジニアはすべてのシステムの開発・修正に関与できるようになります。 しかし、誰でも自由にすべてのソースコードを変更することができてしまう
サービスのリリース
ネットのサービスは新しいバージョンのサービスを頻繁にリリースする。2000年頃は1〜2週に1度の頻度でリリースをしていたが、現在では頻度が上がり毎日リリースしている企業も多い。 大きなサービスのリリースプロセスは、毎日決まった時間(たとえば朝10時)に始まり、リリースを担当するリリース・エンジニア(リリース・マネージャーという場合もある)がリリース・プロセスを進行する。リリース・エンジニアは専属のチームがある場合と、開発チームのエンジニアが当番制で担当する場合がある。 毎日のリリースでは基本的にそのサービスのソース・リポジトリの最新状態(trunk)をリリースすることになる。Trunkがリリースできるためには、trunkがビルドできることと、機能にバグがないことが必要だが、最新の状態が完全に機能するとは限らないので、それは次のような方法で対処する。 trunkへのコードのチェックインをする
Google社内でのソースコード管理には「ブランチ」は使わない | スラド IT
Googleが開催している開発車向けイベントGoogle Test Automation Conference（GTAC）にて、Google社内での開発手法について発表されていたとのこと（発表資料、発表動画、Google の巨大レポジトリとブランチ無し運用 — Kato Kazuyoshi）。 これによると、Googleでは40以上のオフィス、1万5000人以上の開発社、5000以上のプロジェクトが存在するそうなのだが、これらプロジェクトで開発されるコードはソースコード管理システム内の単一のツリーに格納されており、どのプロジェクトも同一のリポジトリを利用する形になっているらしい。さらに、ソースコード管理システムのブランチ機能は利用せず、コミットはすべて最新バージョン（head）に対して行われるルールになっているそうだ。 これにより、プロジェクト間での使用するライブラリのバージョンが統一でき
Google の巨大レポジトリとブランチ無し運用 - Kato Kazuyoshi
GTAC 2013 Opening Keynote の Evolution from Quality Assurance to Test Engineering (スライド) を見た。 スライドの7ページ目 によると、Google では 15,000 あまりの開発者が、40 あまりの拠点に分散している。そして、彼らはひとつの巨大なレポジトリで、ブランチなしに開発しているらしい。 Single monolithic code tree with mixed langauge code Over 100 million lines of code. 50% of code changes monthly. Development on one branch - submissions at head 講演ではこの理由について One of the benefit is that we don’
Gitのカレンダー | Advent Calendar 2012 - Qiita
About reserved postingIf you register a secret article by the day before the same day, it will be automatically published around 7:00 on the same day. About posting periodOnly articles submitted after November 1 of the year can be registered. (Secret articles can be registered anytime articles are posted.)
バージョン管理ソフトウェアの寿命は10年？
Gitが10年後存続してるとは思えないけど、Excelが10年後に消えてる筈がないだろ！！と熱弁してる — （あんちべ 心はS式とともにあります） (@AntiBayes) December 5, 2012 言うまでもなく、gitは今をときめく流行のバージョン管理システムである。たったの10年後に存続していないのだろうか。 gitが登場したのは2005年だ。githubが登場したのは2008年だ。githubは直接関係がないが、gitの価値を押し上げたといえる。それ以前、自由なソフトウェア実装によるバージョン管理システムといえば、Subversionが有名だった。Subversionは、2000年に登場している。2010年、gitは流行していた。いま、SVNがgitの流行に押されているのを考えると、たったの10年でよく変わったものだ。 Subversion以前、自由なソフトウェア実装で有名
Capistranoでアプリケーションのデプロイ作業を効率化 - builder by ZDNet Japan
本連載の第1回から第3回までは、主にmoonlinxのインフラ技術を説明してきました。今回からはmoonlinxのウェブアプリケーション技術に着目して解説していきたいと思います。 デプロイツール「Capistrano」の魅力 ウェブメディア「moonlinx」では、moonlinx Membership Centerと呼ばれるクリエイター向けの登録制会員サービスを運営しています。これは、デザイナーや音楽活動を行うアーティストをターゲットとしたサービスであり、クリエイター自身の活動をプロモーションするツールとして活用できるサービスです。 このMembership Centerでは、フレームワークとしてRuby on Railsを利用して開発しています。また、PhusionのPassengerを利用して、Apache2上で動作させています。 Railsの運用環境は、MongrelとMongre
Free Mercurial and Git Client for Windows and Mac | Atlassian SourceTree
A free Git client for Windows and Mac Sourcetree simplifies how you interact with your Git repositories so you can focus on coding. Visualize and manage your repositories through Sourcetree's simple Git GUI. Simple for beginners Say goodbye to the command line - simplify distributed version control with a Git client and quickly bring everyone up to speed. Powerful for experts Perfect for making ad
Bazaarでござ～る。猿でもできる分散バージョン管理“超”入門
Bazaarでござ～る。猿でもできる分散バージョン管理“超”入門：ユカイ、ツーカイ、カイハツ環境！（20）（1/4 ページ） 「“分散”バージョン管理は難しい」という人こそ 最近、GitやMercurialが注目を浴び、SubversionやCVSなどの中央型のバージョン管理システムに代わり分散型のバージョン管理システムの普及が進んでいます。本稿では、GitやMercurialに比べ、いま一歩マイナーな分散バージョン管理システムである「Bazaar」を紹介します。 本稿は、想定読者層としてはSubversionやCVSを、すでに使っており、分散バージョン管理システムに興味がある方を対象としています。「分散バージョン管理システムって何？」と思われる方は、連載第3回の「分散バージョン管理Git/Mercurial/Bazaar徹底比較」を参照しておくとスムーズに読み進められると思います。 なお
ここギコ！: iPhone水平展開開発：Xcodeでコードと案件毎リソース／設定の分離
Xcodeでの開発で、バージョン管理システムを使っておられる方って、特にブランチばりばり切って開発されてる方とか、どうやって運用されているのでしょうか...。 AppName.xcodeprojディレクトリの下の、project.pbxprojファイルって、ブランチ間のマージが気が狂いそうになるほど大変じゃないですか？ 中を覗いてもどこで何が設定されているのか判らないし、適当にマージしてみれば、Xcodeで読み込んだ時に必要なリソースへのリンクがターゲットから外れてて不具合の原因になったりして、時々泣きそうになります。 1プロジェクト＝1案件であれば、まだ大変さもそこまでではないかもしれませんが、コードを共有する汎用アプリプロジェクトの中で、リソース等を変更した複数の水平展開アプリをターゲット設定する時とか、マジ死ねます。 trunkのコードをいったん凍結して、新規開発はbranch
git-svnの使い方を覚えた - idesaku blog
分散SCMを使いたい！と思う今日この頃。 仕事ではSVN（Subversion）を使っているのだが、ちょっとしたお試し編集をするためにブランチを作ることに抵抗がある。ブランチは欲しい、大きめな変更をコミット無しで行いたくない、やはり少しずつコミットして進めていきたい。しかし、変更が全て記録されてしまうのがいただけない。ログが残るのは良いことなのだが、本当に使うかどうか未知数な実験的プログラミングのログまで残したくない。使うと決まってから初めて残すようにしたいのだ。 すまん、これまで一緒に仕事をしてきた人々よ。俺はこれまで「ログが残って困ることがなんかある？いらなきゃ無視すればいいだけなんだから、気にするな。ブランチでもなんでもバンバン作ってしまえ！」とうそぶいてきているわけだが…ハッタリかましてました！本当は俺も抵抗があるのだ。 そこで、分散SCMだ。さらにいうと、SVKがいまひとつ気に入
git 環境のセットアップと簡単なチュートリアル - LukeSilvia’s diary
ソーシャル化するOSS開発者たち − ＠ITとGitHub Issue Tracker! - GitHubを見て、github がとても楽しそうなので、git を使い始めました。 http://github.com/lukesilvia/ 良く使いそうなコマンドとかを調べたのでメモ。 git インストール インストール Mac なので、macports 使う $ sudo port install git-core +svn +gitweb $ git --version git version 1.6.2.1 今までsvn 使っていて連携したので「+svn」 gitweb あると、ブラウザからリポジトリをブラウズできるので入れる PATH を通す 以下をPATH に追加 /opt/local/libexec/git-core git の場合、git rm とかの後にファイル名の補完が効か
バージョン管理の履歴をビジュアル化·Gource MOONGIFT
GourceはWindows/Mac OSX/Linux向けのオープンソース・ソフトウェア。ソフトウェア開発とはクリエイティブな作業であり、まるで生き物のように成長していく。自作のソフトウェアを我が子のように可愛がる人がいるのも理解できる。 バージョン管理をビジュアル化 そんなソフトウェアの歴史を管理するのがバージョン管理だ。そしてそこに残されたコミットログを使ってビジュアル化するソフトウェアがGourceだ。GourceはGit/Mercurial(Hg)対応のバージョン管理ビジュアル化ソフトウェアだ。 ビジュアル化に何の意味があるかと言われればたいした意味はない。だが一度実行すると時系列に沿ってどんどん成長していく様が面白く、飽きさせない。なお追加のステップを踏めばCVS/Subversionにも対応するらしい。 爆発的に開発の輪が広がっていく まるで木のように成長していくのは、まさに
Hg-Git Mercurial Plugin
the Hg-Git mercurial plugin This is the Hg-Git plugin for Mercurial, adding the ability to push to and pull from a Git server repository from Mercurial. This means you can collaborate on Git based projects from Mercurial, or use a Git server as a collaboration point for a team with developers using both Git and Mercurial. The Hg-Git plugin can convert commits/changesets losslessly from one system
SI業界人は要チェック！！Subversionでのベンダブランチの運用手順。
外部から納品物に自分たちが手を入れるような場合や、他の人が作ったパッケージ製品を改造して提供するような仕事を管理する場合に使えるパターンです。つまり、SI業界には必須ともいえるパターンなはず。 レポジトリにvendorディレクトリを切っておき、その下でベンダから受領したブツを管理する。納品毎にバージョンtagをつける。そこから枝分かれさせたものを、自分のプロジェクトのサブディレクトリとして管理していく。こうやって管理することで、ベンダからの受領物を自分のプロジェクトにマージするときに、SVN力をいかんなく発揮させることができます。 参考：http://hide.xsv.info/tips/svnmanual/merge3/ 今更な人には今更だろうけど、今更じゃない人には今更じゃないよっていうのがこのセカイですので、もう気にしてません。サンタさん、僕はオトナになったよ…。 レポジトリの構成（
Google CodeでMercurialを使う - os0x.blog
先日のGoogle I/OにてGoogleWaveの影でこっそりと、Google CodeでのMercurialのサポートが全面的に公開されました。 The Google Code Blog: Mercurial Now Available to All Open Source Projects (それまでは限定的にMercurialが使える状態でした) 日本ではgitの方が優勢のようですが、MercurialはPage not found - VecTraceやTortoiseHgなど開発環境が揃っている点が魅力的です。 今までは手軽なHosting先がなかった点がネックだったわけですが、Google Codeが正式に対応したおかげでMercurialを始める準備が整いました。 僕が知らなかっただけで、Free source code hosting — Bitbucketという素晴らし
Wordで差分管理するのは現実的？
@coelacanthが書いた記事が興味深かったのでトラックバック。 差分が取れないというのはもちろんですが、仕様書やチャートなどをバージョン管理することの効果は大きいですよね。 周りの人に聞くと、あんまり賛同してれる人もいない・・・。 あらま、自分は一応やっている派です。 WordではなくWikiですが。 wordを利用した場合の解決策 Wordで履歴管理しようとすると選択肢が限定されてくるように感じます。 思いつくのは、以下の方法(実際に全て検証しているわけではありません)。 Word自身のdiff/履歴管理機能を使う(Diff:ツール→文書の比較と反映) 履歴管理に関しては、Word内部で独自管理されるのでリビジョンの意味がなくなってしまうので、バージョン管理システムと相性が悪いように感じる。 xdocdiffを利用する(Windows限定) ローカルだけではなくTracやRedmi
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://docs.sun.com/app/docs/doc/805-5827/6j5gfrans?l=ja&a=view
Amazon.co.jp: Subversion実践入門:達人プログラマに学ぶバージョン管理(第2版): Mike Mason (著), でびあんぐる (翻訳): 本
