こんにちは、以前「[git] クローンからプルしてマージ、コミットしてプッシュする」分散バージョン管理がはじめての方に向けて、Git(ギット)の基本学習用チュートリアルを公開しました。
読んで頂いた方々からいろいろな要望を頂きました。
その中でも多くの方が Windows 環境で利用できる GUI クライアントツールの解説がほしい。という要望です。
Git の基礎勉強はコマンドベース(CUI)である Git をつかったバージョン管理の考え方と使い方を理解してもらうために作成しました。
バージョン管理の基礎を理解している人たちに向けて Windows 環境で利用できる GUI ツールのチュートリアルを作成しましたので公開します。
TortoiseGit の基礎勉強 ~ TortoiseGit によるバージョン管理 ~
Windows にて Git を使いたい方におすすめする TortoiseGit のチュートリアルです。
こんにちは、tracpath はエンタープライズ向けに Git / Subversion / Mercurial のソースコード管理サービスを提供しています。エンタープライズ向けに求められるデータの安全性とセキュリティ対策についてまとめました。tracpath を運営している株式会社オープングルーヴの取り組みについても説明します。
利用者のデータを扱う上で tracpath が備えているセキュリティ機能と tracpath を運営するオープングルーヴの情報セキュリティ管理方針の基本になる2つがあります。
セキュリティ機能は tracpath がセキュリティ向上のために標準で備えているセキュリティ機能です。全てのプランの標準機能として提供しています。
tracpathはインターネット上の通信データをすべて暗号化します。詳しくはこちら
IP接続制限による、指定したグローバルIPからアクセスを許可することでセキュリティを向上させます。詳しくはこちら
アカウントのロックアウトは不正な操作、異常な操作（主にパスワードの試行）が行われたアカウントに対してアクセスを自動的に遮断します。詳しくはこちら
アカウントアクティビティとは tracpath に関する最近のアクセス状況が表示されます。 これは、あたなのアカウントによる tracpath へのアクセス状況を確認することで不正にアクセスされていないか、知らない場所からの不正なアクセスがないか、調べることができます。詳しくはこちら
利用者様が利用するセキュリティ対策の機能を説明しました。ブログではさらに詳しく解説していますのでセキュリティ記事を参照してください。
情報セキュリティ管理とはサービスを運営する当社社員に関係する利用者データの安全性を担保するために設けている決まりです。セキュリティ行動規範として常にアップデートし、インターネットに公開しています。
セキュリティ行動規範は「tracpath」を運営している株式会社オープングルーヴが社内のセキュリティ管理のために利用する文書です。 当サービスにおける情報セキュリティの取り組み状況について現状を通知するために公開しております。
tracpathのクラウドサービスは、エンタープライズ環境において求められる高いレベルの安全対策が施されたサービスとして設計しています。お客様の大切なソースコードや設計情報を守るために実施しているtracpathクラウドサービスのセキュリティ対策とセキュリティ管理について詳細を公開しています。
tracpathが提供しているセキュリティ対策以外に利用者に守っていただきたいルールがあります。利用者のプロジェクトチームや会社で徹底することを期待しています。
主に大規模な開発プラットフォームとして、tracpath を利用するお客様に向けたサービスがあります。
tracpath Enterprise Planはお客様の要望に合わせたソリューションを提供しております。
例えば、自社のデータセンターとtracpathをVPNによるセキュアな環境を構築したり、開発チームのアクセスログ、統計情報を提供するサービスなど….
tracpath を社内の開発チームに導入することが可能です。
セキュリティに対するご質問・お問い合せはこちらからお問い合せ下さい。
tracpathはプロジェクトの履歴を追跡し、インシデント管理（チケットシステム）と同じくらい価値のあるソースコードの変更履歴をブラウザで簡単に見ることが出来ます。
リポジトリブラウザの機能について紹介します。
tracpathのリポジトリブラウザは、ソースコードのチェンジセット、リビジョン、ブランチ、タグ、差分を閲覧するための効率的な機能を提供しています。
さらに、tracpathはソースコードとチケット、Wiki、マイルストーンが密に連携したり、Git / Mercurial / Subversionのリポジトリに対応しています。
プロジェクトの活動状況をすぐに把握することができるダッシュボード機能があります。
ダッシュボードはあなた専用のプロジェクト一覧機能を提供します。あなたが関わっているプロジェクトの活動状況だけを簡単に確認することが出来ます。
さらに詳細を知りたい場合はプロジェクト毎のページに遷移してください。
ダッシュボードでは主に、Wikiの状況、ロードマップ(マイルストーン)の状況、リポジトリの状況、チケットの状況を簡単な数字にして教えてくれます。
ダッシュボードのグラフでは最近の活動状況ーー画像では2ヶ月間のコミット状況を表示ーーを表示しています。
どんなブラウザからでも簡単にソースコードにアクセスすることが出来ます。チェンジセット、リビジョン、ブランチ、タグ、差分を閲覧できます。
tracpathのリポジトリは分散バージョン管理システムの「Git」「Mercurial」と集中バージョン管理である「Subversion」を利用することが出来ます。
tracpathはプロジェクトに複数リポジトリを作成することが出来ます。
マルチリポジトリは1つのプロジェクト内に複数の開発チームが存在するときや複数のモジュールを開発するときに利用すると便利です。開発チーム、運用チーム毎にメインリポジトリ、開発リポジトリ、リリースリポジトリを作成することも出来ます。
チームの方法に合わせて柔軟で強力なtracpathの複数リポジトリ機能を活用できます。
tracpathのバージョン管理システムは全てのソースコード、バイナリ、文書の変更履歴を保存し続けます。
あなたの開発環境からバージョン管理システムにアクセスすることは当然ですが、ブラウザからでもすべてのチェンジセット、履歴、差分を閲覧できることはとても大切です。
tracpathはGoogle Chrome / Firefox / Internet Explorerであれば効率的なユーザインターフェースを提供しています。
プロジェクトの履歴や活動状況だけではありません。リポジトリの活動状況を瞬時に表示します。
さらに、チェンジセット、ファイル、リポジトリパスは自動でリンクされ詳細を確認することが出来ます。ソースコードの歴史を簡単に追跡できる機能を提供しています。
リビジョンログを一覧表示することができます。リポジトリの活動状況と同じようにチェンジセット、ファイル、リポジトリパスは自動でリンクされ詳細を確認することが出来ます。
ソースコードの歴史を簡単に追跡できる機能を提供しています。
リポジトリブラウザはソースコードの階層構造を表示し、簡単に利用することが出来ます。
デフォルトリポジトリはプロジェクトのメインリポジトリであり、リポジトリ一覧に表示されているリポジトリはサブ機能毎のリポジトリ（マルチリポジトリ）です。
Windows エクスプローラーのようにツリービューとファイル一覧からすぐにファイルを見つけることが出来ます。
すべてのプロジェクトで必ずやっておくべき大切なことがある。それはプロジェクトのビジョンを共有することである。新サービスの開発プロジェクトやパッケージのバージョンアップ開発プロジェクト、顧客向けフルスクラッチのシステム開発などすべてでやるべき仕事である。
プロジェクトのビジョンを共有する必要がある人たちは、プロジェクトに関わる全ての登場人物であり、開発者、顧客・経営者、管理者である。プロジェクトのビジョンを文書として作成することで、このプロジェクトでチームが重視しようとしていることや目指していること、顧客の重視していることや優先順位がまとめられ、プロジェクトのビジョンとして共有される。このビジョンを確立して共有するときに関係者内の利害関係や力の関係でたくさんの意見が出るかもしれない。
関係者に共有することが思いの外難しく時間がかかるかもしれない。
でも、この工程はとても重要なので今使う時間はプロジェクトが佳境に入ったときに使う時間と同じくらい大切である。このビジョンはプロジェクト計画立案や要件定義等の工程でその土台になるべき重要な要素と考える。
私たちがプロジェクトのビジョンを策定するときのフォーマットは以下のようなタイトルが並ぶ。
これを雛形にして、プロジェクト管理者が作成するようにしている。
== ○○プロジェクトのビジョン 1. 目的 2. 要件 3. 目標 4. プロジェクトの進め方 5. 予算・リソース・工数・スケジュール感
はじめにプロジェクトの背景や必要とされる理由が説明されるべきであり、プロジェクトをチームで進めていくためのベースの考えとして共有される目的を明示する。これによりチームは積極的な参加と正しいと思われる方向性を示すことがある。プロジェクトマネージャーが共感しやすい目的やビジョンを説明出来ることは、プロジェクトの価値を関係者に周知する強力なツールとなり、価値ある仕事と言うことを思い出させてくれる。
これまでプロジェクトのビジョン策定後、自分のチームに説明し顧客に説明することで、顧客自身がプロジェクトで達成したいこと、何を求めているのか、がはっきりすることが多々あった。
要件はプロジェクトに課せられることであり、顧客やチームが重視すべきことをまとめる。重視すべき点として予算内に収まるようにすべきか(コスト)、来年の2月までにサービスインすることか(期限)、現場の全ての声に対応した機能か、これらが複数定義されているか、を明示する。
私たちは箇条書きで思いつく要件を書き出し、優先度が高いと思われるリストに並び替えて整理したりする。
目標はプロジェクトで達成したいことーー自分たちのチームがこのプロジェクトを進める上で達成したいことーーを書いておく。
顧客の目的とは関係ない場合もある点を頭に入れておくべきである。
具体的な例として、すでに稼働しているシステムのバージョンアッププロジェクトでは「過去のコードのリファクタリングによるコードの最適化」「DBライブラリのバージョンアップ、チューニング」「Webアプリケーション用フレームワークのチューニング」などがある。その他にも「ペアプログラミングを実践」「コードレビューによるコードの品質を担保する」「テストの自動化ツールをプロジェクトに導入」などがある。
プロジェクトマネージャーを中心にプロジェクトのビジョンが策定され、成果物として必要なことが見えてくる。プロジェクトの進め方では、今回のプロジェクトにおいて最適と思われる開発方法ーーアジャイル開発？ウォーターフォール？ーーやチーム体制、責任の範囲、役割分担などが見えてくる。
自分のチームが得意としている方法・体制を明示する。
必須ではないがチームで共有できる場合、プロジェクトの予算、人的リソースーーだれが参加するのかーー、全体のスケジュール感(詳細なスケジュールはこれから計画されるはずであるが、おおよそのスケジュール感)を共有することは大切なことである。
プロジェクトのビジョンはプロジェクト計画前に作っておくことをオススメする。プロジェクトが始まる前にマネージャーが時間を確保し作成することでプロジェクト管理の指針になる。
このプロジェクトのビジョンはプロジェクトが進行中も更新されチームメンバーに共有される。
当社ではいつでも見られるようにtracpathのWikiによりメンテナンスされている。
と言われるような固い話題では無く、開発チームという比較的小さなグループでの情報共有に Wiki を活用している話をしたいと思う。
WikiというシステムはWikipediaが有名である。ブラウザを使ってだれでも簡単に文書編集ができるウェブアプリケーションである。
このWikiシステムは小さな開発チームの情報共有にとても有効に機能する。
tracpath 開発チームでは、開発初期からWikiを使って情報共有をしてきた。
Wikiを導入するに当たって、当社の場合は厳密な運用ルール、記載ルールなどほとんど設けなかった。利用者が好きなように使ってイイですよ。というスタンスでかるく始めた。
唯一のルールと言えるものは、プロジェクトに関するすべての情報 ー技術情報、仕様、ミーティング議事、顧客の声、Excel/PowerPoint/PDFなどーをすべて一元化すること、である。
この唯一のルールは今も変わらず続いている。
このルールのおかげで何度も助けられたことがあるのでプロジェクトが始まるタイミングで開発チームにとっての情報集約できる場を用意しておくことの重要性がみんなに理解された。
ブログのように一般に受け入れられるのは難しく、だれでもすぐに使えるというツールではないのかもしれない。
Wikiのメリットである、Wiki記法を使えるようになって初めて文書作成の簡単さ ー文章の内容だけに集中して書くことが出来る、Word や PowerPoint の書式や改ページと戦う必要が無いー が理解できると思う。
最近のWikiシステムは必ずWYSIWYG機能というワープロのように文書を作成出来るツールも提供されているが、Wikiのよさを殺している気がしておすすめしない。やはり、Wiki記法によるスピーディな文書作成がWikiシステムの重要な点だと考えている。
プロジェクトに関するその時の情報をできるだけ記録しておくことで、数ヶ月後に発生するトラブルに対処できるかもしれないし、将来のメンバーにとって役に立つかもしれない。
このような気持ちで文書を残すことを考えると、Wikiシステムは最適だと思う。
当社のプロジェクト管理サービス「tracpath」は Wiki 機能を標準提供しているので、Wikiのみをフルで使いたいと言う場合、無料で利用することが出来るのでオススメです。
過去のブログで具体的な機能を紹介しているのでそちらも参考にしてください。
「Tracマクロによる仕事に使える厳選マクロと使い方」
Tracのデザインをtracpath風に変更するTracpathThemeプラグインを紹介します。このプラグインを使うと、Tracのデフォルトのデザインがtracpath風のデザインに変わります。
https://github.com/opengroove/tracpaththeme
| デフォルト状態のtrac | TracpathThemeの導入後 | |
|
|
|
| blueテーマ |
TracpathThemeプラグインでは上のblueテーマ以外にも以下の4色のテーマも使用できるようになります。
|
|
|
|
| purpleテーマ | yellowテーマ | greenテーマ | redテーマ |
それではTracpathThemeプラグインの導入方法を説明します。なお、TracpathThemeプラグインはTrac 0.12かTrac 1.0で使用することができます。
|
| TracLightning3.2.0 のMac風デザイン |
Tracでデザインを変更する方法はいくつかありますが、一番簡単なのはThemeEngineプラグインを使うことでしょう。このプラグインを使用することで、複数のテーマを自由に切り替えてデザインを変更することができるようになります。Trac Lightningでは最初からインストールされていて、デフォルトのMac風のデザインにはこのプラグイン用に作成されたテーマが使用されています。TracpathThemeプラグインもThemeEngineプラグイン用のテーマとして作成されています。
ThemeEngineプラグインはeasy_installやpipを使って簡単にインストールできます。なお、Trac Lightningには最初からインストールされているのでこの手順は不要です。
> easy_install --always-unzip TracThemeEngine
あるいは
> pip install TracThemeEngine
インストールが完了したらtrac-adminコマンドでプラグインを有効にします。この手順もTrac Lightningでは不要です。
> trac-admin /path/to/projenv config set components "themeengine.*" enabled
TracpathThemeプラグインもeasy_installあるいはpipを使ってインストールします。
> easy_install --always-unzip https://github.com/opengroove/tracpaththeme/archive/trunk.zip
あるいは
> pip install https://github.com/opengroove/tracpaththeme/archive/trunk.zip
インストールが完了したらこれも同様にtrac-adminコマンドで有効化します。
> trac-admin /path/to/projenv config set components "tracpaththeme.*" enabled
上で行った設定をTracに認識させるために、Tracを動作させているWebサーバを再起動します。
テーマの切り替えは管理コンソールから行います。最初はこんな状態になっています。
まずソースコードリポジトリからスクリーンショット画像の画像ファイルを入手します。
> svn export http://trac-hacks.org/svn/themeengineplugin/trunk/themeengine/htdocs/default_screenshot.png
このファイルをThemeEngineプラグインのインストール先にあるhtdocsディレクトリにコピーします。
> python -c "from os.path import join, dirname; from shutil import move; import themeengine; move('default_screenshot.png', join(dirname(themeengine.__file__), 'htdocs'))"
左右の矢印ボタンでテーマを切り替えてUse this themeボタンでテーマを選択します。Tracpath_blueテーマを選択すると以下のようになります。
選択した結果はすぐに画面に反映されます。
あるいは、インストールしたThemeEngineプラグインのソースコードを修正することで解決することもできます。
まず、修正が必要なファイルの場所をを見つけます。
> python -c 'import themeengine; import os.path; print os.path.dirname(themeengine.__file__)'
上記のコマンドで見つけたディレクトリにあるadmin.pyファイルの63行目を以下のように変更します。
data['themeengine']['current_index'] = index
data['themeengine']['info'] = data['themeengine']['info'][index:] + data['themeengine']['info'][:index];
data['themeengine']['current_index'] = 0
修正後に、Tracを動作させているWebサーバを再起動してください。なお上記の修正方法はThemeEngineプラグインのバージョン2.2.0を対象にしています。
「開発チームの生産性を上げたい」「チームの情報共有化したい」「サービスの品質を上げたい」
プロジェクト管理ツールが解決すると謳っている課題である。ツールを導入したからといって生産性や情報共有化などの数値化しにくい点が改善した、と証明することは難しい。チーム全体が変わった気がする、前よりスケジュール遅延が少なくなったなどの感覚値で語られることが多い。
それなりの費用をかけてプロジェクト管理ツールを導入したけど、一部の人たちしか使っていない。数字をいじる仕事の人だけー管理者やリーダーのみーという声を聞く。
これまでいろいろな開発チームを見てきて、開発ツール等の選定、導入をサポートしてきた立場から
うまくいっている状態(チーム)に見られる特長として、チームのボトムアップでの盛り上がりとチーム全員がそれなりに使うことができる共通言語になる場(ツール)になれるかどうかだと思った。
ツールはあくまでもチームを成長させるためのきっかけにすぎないのではないかと思う。
医療業界向けに業務サービスを提供している約60名ほどの企業(エンド企業)でのこと。社内の基幹システム運用やホームページ、ウェブシステムの管理、運用まで4,5名の情報システム部が担当をしている。ただし、システム開発ができる技術者はおらず、外部にアウトソースしていた。開発会社として2社(A社、B社)といつくかのプロジェクトを進めていた。
エンド企業ではSI企業で開発経験があり、システムに詳しく業務知識に明るい担当者が管理者(リーダー)として、すべての開発プロジェクトのとりまとめを行っていた。情報システム部門メンバーの進捗管理から外部の協力会社との仕様取り纏めなども管理しなければならず、いつも忙しい状態が続きそれが普通になっていた。
このまま何事も無くリーダーの管理で仕事はスムーズに進めばよいのだが、、、これまで体調不良で数日休むことがあり、業務に致命的な穴が空くことが何度か発生したらしい。
1人の優秀な人のスキルに頼り切った状態で運用されていたため、その人がいないというだけで情報システムメンバーは穴を埋めることが出来なかった。メンバーからするといきなりリーダーがやっていた作業を引き継いで進捗管理から外注管理まで・・・無理な相談である。
開発チームの生産性向上、チームの情報共有に効果があると思われるツールを入れて試用版をいくつか試してみた。約1ヶ月試用してみたけど、メンバーは最初ちょっと使うだけ、いつのまにか見向きもされなくなってしまった。
ツールが役に立たない訳ではない。ちょっとしたリーダーの作業とチーム体制を変えたことでこの後、ーチームに導入、浸透するまで2，3ヶ月の時間が必要だったー一気にツールのメリットが享受されるようになった。
新しい体制図では、これまで利用するツールが決められていなかったーメールに記載したり、Wordで書いたり、電話だったり..ーがツールを一元化しクラウドサービスに統一したことである。
外部の協力会社と一緒にプロジェクトの情報共有ができ、だれが、何をしているのかを見ることが出来る。
プロジェクトを進めるときに関係者が共有ツールを手に入れることでコミュニケーションコストの削減が実現ーコミュニケーションコストの削減は効率化に直結するーした。
これは、関係者で共通言語「今週中に対処が必要なレポートで進捗確認しよう」「#441 チケットにコメント書いたので、内容チェック後、コメントください。」「A社の提示した資料のチェックがまだです。いつまで？」が自然にできあがったためである。
もう一つ、重要な点はエンド企業の大きなシステム毎に専任の担当者を任命したことである。
社内の業務システム担当者とホームページやウェブシステムの担当者の2名である。
これによって、プロジェクトチームに推進力が生まれ数ヶ月後に多くの課題が解決されることになった。
まだまだたくさんの課題は残っており、体制とツールですべてが解決できたわけではない。
しかし、2，3ヶ月という期間でチームの風通しが良くなりプロジェクトが前に進んでいるという実感をチーム全員が感じていることはとても意義がある。
小さなチームのちょっとした改革によって前より少しだけよいチームになった。
この小さな改善のサイクルを繰り返すことがとても重要である。
みなさん、BTSを使っていますか。
BTSを利用するメリットは十分理解しているし、チームにも浸透している。と思いますがバグ報告、チケットを作成する点だけはどうしても面倒に感じています。
プロジェクトによってはバグ報告用のフォーマットを決めていたり、開発者からできるだけ詳細な情報を記載するように指示があったり、バグ報告のレポートはそれなりの要求が求められるため起票することを面倒に感じるのではないか。と考えています。
例えばバグ報告の場合、テキストデータのみでやりとりすることになるため
などを正確に記述することが求められます。
プログラマーにとってバグの原因究明にとても役立つ有益な情報ですが、毎回起票する側（テスターなど）にとってみれば手間が掛かります。とくにスケジュールが大幅に遅れている場合やお客様からせっつかれているときなど起票せずに口頭で…となりがちです。
最近のOSやアプリケーションにはクラッシュレポートツールや自動報告ツールが用意されていることがあります。
例えば、Mac OS X や Firefox などです。
業務アプリやウェブサービスでは製品の開発と同時に、その製品に組み込むクラッシュレポートツールを開発している、というのは聞いたことが無いですが同じような仕組みでバグ発生時の情報を自動収集してくれるツールが欲しいなと思いました。
オープングルーヴは、tracpathというクラウド型バグ管理サービスを開発・運営しており、テスターのバグ報告ツールとしてfulmo(フルモ)というスクリーンショット付きバグ報告ツールをオープンソースで提供しています。
fulmoはブラウザのプラグインとして動作するブラウザ拡張ツールのため、クラッシュレポートツールのような高度なことは出来ないかもしれませんが「これからのバグ報告ツールに必要なこと」にある「バグの再現手順を自動再生」「過去のバグ発生箇所の履歴と見える化」「バグ発生時点の詳細情報を自動取得」は実現したいと思いました。
tracpath version 1.13 リリースをお知らせします。
本日、tracpath のリリースを実施しました。
ご利用のお客様は新しい機能を利用する事が出来ます。ぜひご利用下さい。
ご要望やバグ報告を頂きました皆様、まことにありがとうございます。
これからもどうぞよろしくお願いいたします。
今後もさらなる改善をおこなってまいります。
ご要望やご質問はこちらまでご連絡ください。
tracpath の新UIデザイン「フラットデザイン」が利用できるようになりました。
新たに6種類のデザインが追加されました。
プロジェクト毎に好きなデザインテーマを利用することが出来ます。
「プロジェクト」->「管理」->「色設定」から設定を変更してください。
すでに利用頂いているお客様のプロジェクトは旧テーマカラーのまま変更されません。
新UIデザインをご利用になる場合は、管理画面より設定を変更する必要があります。
新規プロジェクト作成はすべて新UIデザインが適用されます。旧デザインに変更することも可能です。
これからもどうぞよろしくお願いいたします。
今後もさらなる改善をおこなってまいります。
ご要望やご質問はこちらまでご連絡ください。