chefからansibleに乗り換えた5つの理由｜TechRacho by BPS株式会社
1年くらいchefを使ってサーバ構築をしていたのですが、最近ansibleに乗り換えたので紹介記事を書いてみます 1. サーバ側に何もインストールする必要がない chefは管理対象ノードにchef-clientをインストールする必要がありますが、ansibleはPython 2.4が入っていて、sshでログインできればOKです。 chefもパッケージや,knife bootstrapコマンド等があるので始めやすいですが、何もする必要がないansibleの方が敷居が低いのかなと思ってます。 例えばsshでログインできれば、以下のコマンドを打てば10.0.10.1～10.0.10.3サーバの情報をとってくれます(カーネルバージョン,CPU,メモリ,ディスクサイズ,ディストリビューション等)。 この機能はchefで使われているohai相当のことをしてくれます。 echo 10.0.10.1 >
提言: コミットメッセージの一行目には要求仕様を書け - Qiita
これは Git (や Subversion などのバージョン管理システム) にコミットする時により良いコミットメッセージを書くための提言です。この提言は特にメッセージの一行目だけを対象とします。せめて最も重要な一行目だけでも良いメッセージを書いて欲しいからです。提言をズバリ一言で表すと 一行目には要求仕様を書け です。 背景 プロジェクトによっていろいろ慣習の差はあるものの、一般的には「コミットメッセージの一行目は変更内容の要約を簡潔に書け」とされます。特に Git は、各コミットメッセージの一行目だけを取り出してそれを一覧表示するなど、一行目を特別に処理する機能が多いので、一行目にできるだけ多くの情報を凝縮させることは重要です。またメッセージを一行しか書かない不届きな慣習のプロジェクトでは、十分な情報を持たないメッセージは無用の長物と化します。 良くないコミットメッセージ しかし私は、情
追記専用のファイルでコンフリクトを抑止する - Qiita
ChangeLog とか Android アプリの string.xml の様に、特定の箇所に行が追加されていくだけのケースで、複数の人が作業すると頻繁にコンフリクトが発生してしまいます。 大抵のバージョン管理システムではファイル毎にマージに使うコマンドを指定できるようになっていますが、 git の場合は .gitattributes ファイルで指定します。 $ echo "string.xml merge=union" >> .gitattributes $ git add .gitattributes $ git commit -m "string.xml: merge=union" merge=union の部分がマージドライバーの指定で、 union は順番を気にせずに両方の内容を保存するマージドライバーです。 このドライバーを使うと同じ行を別々の人が追加した時に重複してしまう可能
本の虫: Bazaar-NG: 分散バージョン管理システムを7年ハックしてきて
Bazaar-NG: 7 years of hacking on a distributed version control system Bazaarの開発者が、Bazaarが失敗した理由について、当時を振り返って書いている。なかなか面白い。 Bazaar-NG: 分散バージョン管理システムを7年ハックしてきて この7年間、筆者はBazaarプロジェクトに関わってきた。筆者はプロジェクトから距離を置き始めている今この時、筆者のこのプロジェクへの関わりや、何が良くて何が悪かったのかの意見などを、振り返ってみるべきだと思う。 この回顧録には多くの複雑な詳細が出てくるので、筆者の誤りもあるかも知れない。間違いを見つけたら知らせてくれ。 黎明期 < ddaa> dscmsには2種類ある。古臭いやつと、実験中なやつ。 2004年、筆者は、 SambaのコントリビューターであるMartin Pool
git による分散作業パターン | GREE Engineering
分散バージョン管理を華麗に扱いたい堀口です。 GREE Advent calendar 2013 の 14 日目として参加させていただきます。 お二人に続き Haskell の話をしようかと思ったのですが、急遽無難な開発の話に変更しました :o Java や C++ には OOP の概念が必要であったように、分散作業の認識が薄いまま git や Mercurial を使うことは長期的に不幸をもたらします。 とあるプロジェクトにて、その一部を副産物のミドルウェアとして抽出すべく、アプリケーションと分離したい 不具合があったので原因を探りたいが、依存関係が複雑すぎるのでコードを読む量を減らしたい テストやレビュー、提案、リファクタの運用を強化したい よそのプロジェクトに迷惑を掛けないように、そこのツールを改良して使いたい。 いままで何気なく「こんなもんだろう」と思って手間をかけていませんでした
Git 対 Mercurial：なぜ Git を選ぶのか？ - Atlassian Japan
今回は Atlassian の開発者である Charles O’Farrell によるゲストブログです。チームが DVCS として Git を選択する理由について説明します。Charles はコーディングをほとんど DVCS 上で行い、また ClearCase から Git へユーザーを移行させる作業を行ってきました。 前回の記事では、分散バージョン管理システムとしてチームがなぜ Mercurial を選択するのかについて考えてみました。今回は、分散バージョン管理システム (DVCS) として なぜ Git が有力な選択肢であるのかについて考えてみましょう。 1970 年の黎明期から、ギークたちはどちらが善でどちらが悪かという血なまぐさい論争を長い間行ってきました。それが Vim と Emacs との間の戦いです。最近では、それとは別のツールセットについて、ギークたちは本来の仕事そっちのけ
A successful Git branching model を翻訳しました
Vincent Driessenさんの "A successful Git branching model" を翻訳しました。 元記事はこちら： http://nvie.com/posts/a-successful-git-branching-model/ （翻訳の公開と画像の利用は本人より許諾済みです） このブランチモデルの導入を補助してくれる、git-flowというGit用プラグインがあるそうです。 翻訳の間違い等があれば遠慮なくご指摘ください。 A successful Git branching model この記事では、私のいくつかのプロジェクト（仕事でもプライベートでも）で約一年ほど導入して、とてもうまくいくことがわかった開発モデルを紹介する。しばらく前からこれについて書くつもりだったんだが、今まですっかりその時間を見つけられずにいた。ここでは私のプロジェクトの詳細については書
Accueil
Paris, la ville lumière, s'enrichit d'une nouvelle attraction sensationnelle qui fera le bonheur des amateurs de sensations fortes et des fans de super-héros. Le Batman Escape Game a ouvert ses portes, proposant une expérience immersive unique dans l'univers du Chevalier Noir. Ce nouvel escape game situé en plein cœur de la capitale promet de devenir un incontournable pour tous... Les transactions
チケット駆動と分散バージョン管理 - torutkのブログ
実は、チケット駆動開発はいいなぁと思いつつ、チケット駆動開発は習慣化が必要で、習慣化するまでは非常に努力を要するため、今までちっとも実践できずにいました。 最近、地理的に離れた複数拠点で、しかもネットワークが断絶に近い状態で、同一ソフトウェアを開発する都合上、それまで使用していたSubversionでの集中リポジトリでは対応できないため、分散リポジトリの一つBazaarを使い始めました。また、拠点間でのソフトウェアの変更反映には、パッチを使用しています。そのため、パッチが多数累積するので、パッチを管理するために、チケットとパッチを結びつけるようにしています。 すると、チケットがないとパッチを作成できないので、必然的にチケット駆動となります。チケットがなく修正した場合も、パッチを送付するためには、パッチと結びつくチケットを作成しなくてはならず、後追いでもチケットが作られます。 分散バージョン
gist.github.com で GreaseMonkey Script を管理しよう - 川o・-・）＜2nd life
http://gist.github.com/ 最近 github にまた新しいサービス、gistが誕生しました。これはよくあるソースコードを web にペーストして参照できるサービスの git 版、と云ったところです。 gist の良いところは、まず git を知らなくても使えるところが上げられます。普通のペーストサービスと同じで、ソースコードを適当にはっつければOKで簡単です。編集ももちろん web 上からでき、インターフェイスから編集を行うと、git の履歴としてサーバサイドに保存されます。また、匿名による作成・編集も可能です。(匿名による編集は cookie が切れるまでっぽいですが) そして、git と同じく、github にログインしてれば、gist で誰かが貼り付けたソースコードを fork でき、自分の権限の元編集操作が可能になります。ので、誰かが貼り付けたコードを for
Mercurial や Git が使える無料のリポジトリサービスを集めてみた - kなんとかの日記
Git を使うなら GitHub で決まりだと思うけど、GitHub は BTS がないし、Git じゃなくて Mercurial を使いたかったので、Mercurial 版 GitHub がないか探してみた。 そのうちにいろんなリポジトリサービスが見つかったので、紹介してみる。 ＃sourceforge.net とか rubyforge.org とかでも repository hosting を提供してるけど、ほとんど使われてないっぽい。 GitHub (Git) http://github.com/ Ruby on Rails が使ったことから一気にブレーク。Rails ユーザは皆ここを使う。 Issue Tracking System がないので、Lighthouse.com と併用することが多い。 Wiki が利用可能 Bitbucket (Mercurial) http://ww
Mercurial の利用
重要: Mercurial の 1.x ⇒ 2.0 では、 コンセプト／操作性／互換性等における大きな改変はありません。 あくまで通常の定例アップデートに過ぎませんので、 従来の版を元に書かれている情報の多くは、そのまま適用可能です。 はじめに ノート PC での移動中作業が多くて 「オフラインでコミット／ブランチ作成／履歴参照／差分参照できない」 ことに不便を感じていたり、 「システム構成例」 に示すような構成管理の仕組みを必要とした経験がある場合、 分散リポジトリ形式を用いる Mercurial は、 試してみる価値のあるソフトウェア構成管理 （SCM: Software Configuration Management） ツールと言えます。 しかし、 CVS などを常用して SCM ツールの原理／概念を理解している人でも、 意外に「分散リポジトリ」という考え方がピンとこない場合が有る
最近みた TechTalks: Mercurial Project
Mercurial という分散 SCM の紹介. Python 製で, シンプル軽量スケーラブルが売り. 開発を初めたきっかけは linux の BitKeeper 事件だという. (だから GIT がライバルらしい.) OpenSolaris や OLPC など, けっこう採用実績があるのに驚いた. 私は分散 SCM を触ったことがない. SVK をちょっとつついたくらい. 話を聞く限り Mercurial はけっこう良さそう. (スライドは Wiki に公開されている.) 分散はさておき軽量なのがいい. たとえばレポジトリのためにわざわざ svnrepos みたいな別ディレクトリを作る必要がない. 作業コピーの中に .hg ディレクトリができて, ここに履歴が収められる. つまり作業コピーのディレクトリでレポジトリが閉じている. svn だとレポジトリを作るのが面倒でバージョン管理を先
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.machu.jp/posts/20100506/p01/
http://www.machu.jp/posts/20090106/p01/
http://www.machu.jp/posts/20080311/