「DevOps」という言葉にもあるように、ソフトウェア構成管理は、インフラ運用に取り入れられるなど、変わりつつある時代だ。本連載では、そのトレンドにフォーカスして、現在のソフトウェア開発に有効な構成管理のノウハウをお伝えする ソフトウェア開発で構成管理が重要になった5つの理由 DevOps時代の開発者のための構成管理入門（1） 開発と運用の協力を目指す「DevOps」含め、いまの構成管理を取り巻くトレンドや、その必要性などを5つの項目で解説する
DevOps時代の開発者のための構成管理入門
「DevOps」という言葉にもあるように、ソフトウェア構成管理は、インフラ運用に取り入れられるなど、変わりつつある時代だ。本連載では、そのトレンドにフォーカスして、現在のソフトウェア開発に有効な構成管理のノウハウをお伝えする ソフトウェア開発で構成管理が重要になった5つの理由 DevOps時代の開発者のための構成管理入門（1） 開発と運用の協力を目指す「DevOps」含め、いまの構成管理を取り巻くトレンドや、その必要性などを5つの項目で解説する
工数削減だけじゃない、自動化ツールの真のメリット
工数削減だけじゃない、自動化ツールの真のメリット：運用自動化ツールまとめ（国内ベンダ編）（1/4 ページ） 運用自動化というと「人員削減」「コストが掛かる」といったネガティブな見方をする向きも多い。だが仮想化、クラウド時代において運用自動化とはそれほど単純なものではない。国内ベンダ4社のツールに真の意義を探る。 仮想化技術の浸透に伴い、2008年ごろから国内でも注目を集め始めた運用自動化。だが、「人が削減される」「コストが掛かる」「万一の時が不安」といったネガティブな見方も多く、導入企業は現在も一部にとどまっている。しかし近年、市場環境変化がさらに加速し、ビジネスを遂行するIT基盤を迅速・柔軟に整備・変更する必要性が増している。こうした中、もはや人手だけに頼った運用では、ビジネス部門の要請に応えられないばかりか、人的ミスも誘発しやすい状況になっている。こうした状況は以下の記事に詳しい。 情
Gitでブランチを操作する
対象読者 今回の対象読者は下記の通りです。 Windowsに関する基礎的な知識 Gitに興味がある方 Subversionなどの別のバージョン管理システムを利用したことがある方 必要な環境 Git for Windows（フリー） Git Extensions（フリー） ブランチとは 何らかのバージョン管理システムを利用したことがある開発者ならば、あえて説明する必要もありませんが、ここで簡単にブランチについて説明します。一言で言えば、バージョン管理システムにおけるブランチとは、任意のリビジョンから別系統の履歴を管理していくために作成される分岐のようなものです。ブランチとは「分岐、枝」を意味し、本系統の方は「幹」に例えてトランクと呼ぶのが一般的です（図1）。 一般的な開発ではトランクで主な開発作業を繰り返します。開発が収束しリリースにむけてトランクとは別に履歴管理をしていきたい場合、ブランチ
Git Extensionsからリポジトリを操作する
はじめに 本連載はWindows上でGitを利用しようとしているユーザー向けに、これから数回かけて解説していきます。今回はGit Extensionを中心に、GUIでの基本的な操作方法について解説します。Git Extensionsとは、WindowsでのGit作業を支援するGUIツール群で、エクスプローラーから簡単に利用できます。 対象読者 今回の対象読者は下記のとおりです。 Windowsに関する基礎的な知識 Gitに興味がある方 Subversionなどの別のバージョン管理システムを利用したことがある方 必要な環境 Git for Windows（フリー） Git Extensions（フリー） Git Extensionによる操作 前回はCUIによる基本的なGitの操作を解説しました。今回は、Git Extensionsに含まれるGUIから同様の操作を行った場合について解説していき
仕事で使ってる巨大SVNレポジトリをGithubに移管するためにやったことまとめ · DQNEO日記
動機 Subversionで困ってない ぶっちゃけSubversionで全然困っていませんでした。 コードレビューはちゃんとやっていたし、マージ・ブランチングも自作シェルスクリプトのおかげてスムーズにやれていました。 よく「Gitはマージが賢い、ブランチ作成が一瞬でできる」とかいわれますが、Subversionだってちゃんと使えばコンフリクトなんかめったに起きないし、ブランチ管理・マージだって全然めんどくさくない。 特にver1.7からはサーバもクライアントも大幅に高速化されたし、.svnディレクトリが.gitみたいに１個になったし、rebaseみたいなことだってできる。(sync merge & reintegrate) ただ、世の中が一斉にGitにシフトしている中でいつまでもSubversionを使っててよいのかという不安がありました。 また、月から金までSubversionにどっぷり
アトラシアンのニコラス・マルドゥーン氏が語る分散バージョン管理によるアジャイル開発
--- まずアトラシアン社の概要をご紹介ください。 ニック 2002年にオーストラリアのシドニーで設立され、現在はサンフランシスコ、アムステルダム、東京にも拠点があります。私が2007年にアトラシアンに加わった時は89人目の社員でしたが、現在では約550名になっています。 アトラシアンのミッションは、世界の様々なチームが素晴らしいソフトウェアを作るための支援をすることです。製品は大きく分けて二つあります。まず、バグ、タスク、プロジェクト、人、ソースコードなどのあらゆるものを管理する、プロジェクト管理ツールの提供です。もう一つはチームがリッチなコンテンツを作成、共有、議論するためのコラボレーションツールです。 アトラシアンのソフトウェアは、エンタープライズでも利用可能であると当時に、数多くのユーザーに使ってもらえるように、価格が非常に安くなっています。実は、私たちの会社にはセールスの担当者は
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 この記事では、私のいくつかのプロジェクト（仕事でもプライベートでも）で約一年ほど導入して、とてもうまくいくことがわかった開発モデルを紹介する。しばらく前からこれについて書くつもりだったんだが、今まですっかりその時間を見つけられずにいた。ここでは私のプロジェクトの詳細については書
A successful Git branching model » nvie.com
Note of reflection (March 5, 2020) This model was conceived in 2010, now more than 10 years ago, and not very long after Git itself came into being. In those 10 years, git-flow (the branching model laid out in this article) has become hugely popular in many a software team to the point where people have started treating it like a standard of sorts — but unfortunately also as a dogma or panacea. Du
【夏サミ2012】B-4セッションレポート グリーが実践する、GitHub Enterpriseによるソーシャルコーディング
OSSの世界で一大ムーブメントとなっているソーシャルコーディング。400人以上のエンジニアを擁するグリーでも、さまざまな開発課題への対策として2012年よりGitHubを採用し、ソーシャルコーディングを実践している。本セッションでは、同社でGitHub導入を推進してきた開発本部 CTO室の大場光一郎氏が、ソーシャルコーディングの企業導入にあたっての課題や留意点、グリーで実際に得られた効果などを紹介した。 誰もが自由にプログラムを変更・公開し、開発元へ還元できる！ 大場氏はまず、GitHub導入以前にグリーが抱えていた開発の課題として、「急激な増員」「業種の増加」「国際化」の3つを挙げた。 急成長する企業の宿命ともいえるが、2010年には200人程度だった社員数が毎月50人のペースで増え続け、2012年には約1400人の規模にまで拡大。グリーでは以前から社内でスカイプのチャットなどをよく活用
［プライベートクラウド編］障害時対応をツールの機能だけに頼ってはいけない
クラウド基盤の構築は、どうしてもテクノロジー優位に進む傾向がある。仮想化や自動化といった比較的新しいテクノロジーを使って、早く安くサービス提供しようとするからだ。しかし、良かれと思って安価に構築したサービスが、規模拡大に伴って問題を抱えてしまうことが少なくない。障害発生時の復旧に時間がかかり、現場の負担増大やサービス停止などが起こる。その結果思わぬコストが発生し、安価なサービスではなくなってしまう。 問題発生の理由は多くの場合共通している。提供しているサービス全体を把握している担当者が小人数しかいない状況で、ハードウエアに付属のユーティリティーソフトの稼働監視機能などを使いこなして何となくサービスを提供してしまうのだ。そして、想定外の事態が起こったときに慌てるのである。 個々のサーバーを個別に運用するのではなく、統合されたシステム基盤として構築するクラウド環境では、ハードウエアやソフトウエ
課題管理対決！Redmine vs. Trac
Redmineの機能と特徴 Redmineは、Ruby on Rails上で動作する、Webインタフェースの課題追跡（Issue Tracking）ツールです。原稿執筆時点（2008年9月現在）での最新のバージョンは0.7.3です。 Redmineが搭載している機能は、「マイルストン設定（ロードマップ）」「カレンダー／ガントチャートの表示（概要）」「作業時間の登録／集計（チケット、概要）」「作業履歴の閲覧（活動）」「課題の登録／追跡管理（チケット、新しいチケット）」「伝言板（ニュース）」「文書の登録／閲覧（文書、Wiki）」「ディスカッション（フォーラム）」「ファイルの共有（ファイル）」「ソース管理との連携（リポジトリ）」「ワークフロー定義」「メール通知」「RSS配信」「ユーザの管理/ロール・権限の設定」です。なお、かっこの中はRedmine画面上で対応する主なメニュー項目名です。 筆者の
SubversionとTracでファイル管理の“迷宮”から脱出
SubversionとTracでファイル管理の“迷宮”から脱出：ユカイ、ツーカイ、カイハツ環境！（2）（1/4 ページ） プロジェクトで修正／仕様変更が“迷宮”入りする理由 ソフトウェア開発を行ううえで、設計書やソースコードのバージョンをきちんと管理することは非常に重要です。構成管理（ファイル管理）を行っていないプロジェクトでは、例えば次のような問題が発生します。 2人以上の開発者が同時に成果物を編集した場合、後に編集を始めた開発者がすでに編集を行った開発者の編集内容を上書きしてしまう。結果として、修正したはずのバグや変更したはずの仕様が、設計書やソースコードに反映漏れするという事態が発生 設計書やソースコードのレビューを行って修正したはいいが、どこをどう修正したのか分かりにくく、レビュー内容の反映の確認を行っても修正漏れや修正誤りに気が付かない ソースコードを変更すると、動かなくなってし
[ThinkIT] 第6回：BTS（Bug Tracking System）の利用 (1/3)
システム開発を進めるにあたり、バグやタスクなどを管理して、現在発生しているバグの数や担当者といったステータスを把握する必要があります。また、ある程度以上の規模のWebアプリケーションを開発する場合、数人のチームで開発を進めるケースが多く、開発を円滑に進めていくためにスタッフ間での情報共有が重要になってきます。 「Bug Tracking System（以下、BTS）」は、これらの問題を解決するためにプロジェクトのバグを管理し、修正状況を追跡できるよう可視化を行うシステムです。現在、BTSとして様々なソフトウェアが公開されており、ソフトウェアを開発する上での必須アイテムになりつつあります。 BTSの多くはWebブラウザ経由でアクセス可能なソフトウェアで、その中から今回はウノウで採用している「Trac」について説明します。 Tracは、BTSとWiki、Subversionリポジトリビューワー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
図とコマンドで分かる！ git-flowによる開発の流れと使い方
和製GitHub「ギットブレイク」公開、プライベートリポジトリが無料・無制限 
Git操作の基礎
プロジェクトメンバーが必ず押さえておくべきマナー～ブランチ戦略の基本
GForge Collaborative Development Environment
バージョン管理を機能させるためにチームメンバーが持っておくべき構成管理という考え方
@IT：旧 IT Architect 連載記事一覧