仕事で使ってる巨大SVNレポジトリをGithubに移管するためにやったことまとめ · DQNEO日記
動機 Subversionで困ってない ぶっちゃけSubversionで全然困っていませんでした。 コードレビューはちゃんとやっていたし、マージ・ブランチングも自作シェルスクリプトのおかげてスムーズにやれていました。 よく「Gitはマージが賢い、ブランチ作成が一瞬でできる」とかいわれますが、Subversionだってちゃんと使えばコンフリクトなんかめったに起きないし、ブランチ管理・マージだって全然めんどくさくない。 特にver1.7からはサーバもクライアントも大幅に高速化されたし、.svnディレクトリが.gitみたいに１個になったし、rebaseみたいなことだってできる。(sync merge & reintegrate) ただ、世の中が一斉にGitにシフトしている中でいつまでもSubversionを使っててよいのかという不安がありました。 また、月から金までSubversionにどっぷり
［プライベートクラウド編］障害時対応をツールの機能だけに頼ってはいけない
クラウド基盤の構築は、どうしてもテクノロジー優位に進む傾向がある。仮想化や自動化といった比較的新しいテクノロジーを使って、早く安くサービス提供しようとするからだ。しかし、良かれと思って安価に構築したサービスが、規模拡大に伴って問題を抱えてしまうことが少なくない。障害発生時の復旧に時間がかかり、現場の負担増大やサービス停止などが起こる。その結果思わぬコストが発生し、安価なサービスではなくなってしまう。 問題発生の理由は多くの場合共通している。提供しているサービス全体を把握している担当者が小人数しかいない状況で、ハードウエアに付属のユーティリティーソフトの稼働監視機能などを使いこなして何となくサービスを提供してしまうのだ。そして、想定外の事態が起こったときに慌てるのである。 個々のサーバーを個別に運用するのではなく、統合されたシステム基盤として構築するクラウド環境では、ハードウエアやソフトウエ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
@IT：旧 IT Architect 連載記事一覧
