tracpath は Git の脆弱性(CVE-2023-23946)および(CVE-2023-22490)への対応のための更新を実施済みです。(2023/02/16)
アナウンスGit
- “git apply” overwriting paths outside the working tree (CVE-2023-23946)
- Local clone-based data exfiltration with non-local transports (CVE-2023-22490)
tracpath は Git の脆弱性(CVE-2023-23946)および(CVE-2023-22490)への対応のための更新を実施済みです。(2023/02/16)
アナウンスGit
分散型バージョン管理システムであるGitには重大な脆弱性が見つかりました。
Gitの脆弱性CVE-2022-41903およびCVE-2022-23521対応について報告します。
tracpath は Git の脆弱性 (CVE-2022-41903)および(CVE-2022-23521) への対応のための更新を実施済みです。(2022-01-25)
アナウンスGit 2.39.1 and others:https://groups.google.com/g/git-packagers/c/UFcv48uFXBU/m/h1hy4r_DAQAJ
https://raw.githubusercontent.com/git/git/master/Documentation/RelNotes/2.30.7.txt
こんにちは、tracpathの便利な機能の紹介です。ソースコードの管理にバージョン管理システムを利用しているときチームメンバーのコミット(commit)を通知して欲しいと思ったことはありませんか。
Git / Mercurial / Subversion のリポジトリで開発作業をしているときチームメンバーのコミットを関係者にメール通知する機能をご紹介します。
tracpathはサポートしているバージョン管理システムに対応した柔軟でパワフルなリポジトリ通知機能を持っています。
リポジトリのコミット通知を受け取りたい場合は、リポジトリにチェックマークを入れるだけでコミット通知されます。これは、Git / Mercurial / Subversion すべてのバージョン管理システムで利用することが出来ます。
さらに大規模なリポジトリや大規模チーム開発で効果的に利用することが出来る、trunk(トランク)、branches(ブランチ)のパスを指定して特定のコミットのみを通知することが可能です。
例えば
設定方法はとても簡単です。プロジェクトのリポジトリ毎に設定を行います。グローバルメニューの「個人設定」->「通知」をクリックしてください。
開発中のリポジトリにコミットされると関係者にコミット通知メールが自動送信されます。
自動送信されるメールの例を以下に紹介します。ここではすべてHTMLメールになっていますが個人設定でテキストメールに変更することが可能です。
tracpathはリポジトリのコミット通知機能をだれでも簡単に利用できるようにし、開発を効率的にしたいと考えています。社内のリポジトリに便利な機能を設定したり、環境を構築したり、、、tracpathを利用すれば、開発者にとって必要な開発環境の整備や保守に時間を使う必要はありません。すこしでも自分たちの製品開発に時間を使って欲しいと考えています。
コミットをメール通知するメリットとして、
エンジニア全員が他のメンバーの作業状況をリアルタイムに把握することでコードを多くの目に触れさせることに意味があると考えています。
ソースコードのコードレビューに繋がり、ソースコードの最適化アイデアやリファクタリングが議論されることを期待しています。
すべては「よりよいソースコードにすること」と「製品の品質向上」に繋がると考えています。
ぜひ、リポジトリを利用されているエンジニアの方は「リポジトリのコミット通知機能」をご利用ください。
こんにちは、あなたの開発チームはどちらのバージョン管理システムを利用していますか。
Git でしょうか? Subversionでしょうか?
最近利用を開始したユーザーからは分散バージョン管理システムである「Git」「Mercurial」の利用やお問い合わせを頂きます。tracpath のサービス開始時は、Subversion のみに対応していたためSubversionを利用しているプロジェクトが圧倒的に多いのが現状です。
LinuxやCUIに慣れたユーザーは、Git,Subversionをすべてコマンドラインで操作した方が分かりやすいし、何よりも操作性、処理速度が速いという意見があり、クライアントツールとして利用します。
「ターミナル(コマンドライン)があればほとんど他のツールはいらない・・・」
開発者は毎日ソースコードにアクセスするためにバージョン管理システムを利用する事になります。
使い慣れたツールがもっとも開発効率が高くなるため新しく分かりやすいツールがリリースされても移ることは少ないと思います。
でも、初心者やバージョン管理システムを使い始めたばかりのユーザにとって、GUIを持つアプリケーションの使い勝手はとても良く、多くの便利な機能と視覚的なサポートがあり利用する人を増やしています。
結局、どのようなツールを使うかではなく、「何を開発するのか」「ツールで目的が達成できるのか」が重要になってくると考えます。
これからバージョン管理を使ってみようと思っている方を対象に、Gitのクライアントツールで有名な「TortoiseGit」と「Git Extensions」を使ったバージョン管理の基礎勉強(チュートリアル)とSubversionのクライアントツールで有名な「TortoiseSVN」の基礎勉強(チュートリアル)を紹介します。
このチュートリアルをレッスン1から実行することで、基本的なバージョン管理の機能を試すことが出来ます。チュートリアルは30分〜1時間くらいですが膨大なマニュアルを読む前に仕組みを把握することが出来ますのでぜひ挑戦してください。
TortoiseSVN の基礎勉強 ~ TortoiseSVN によるバージョン管理 ~
TortoiseGit の基礎勉強 ~ TortoiseGit によるバージョン管理 ~
Git Extensions の基礎勉強 ~ Git Extensions によるバージョン管理 ~
こんにちは、皆様はバージョン管理ソフトウェアとして何を使っていますか。
tracpath はエンタープライズ向けの利用者が多く、Subversion がトップでその次が Git の利用者が多くなっています。
組込みシステム開発のお客様の中で何十年と開発が継続している製品のバージョン管理ソフトウェアとして、「CVS」を利用されているお客様がいらっしゃいます。
新しいプロジェクトは tracpath の Subversion 環境をご利用頂いていますが、過去から継続している CVS プロジェクトだけはできない理由があるようです。担当者としては新しいバージョン管理の優れた機能を利用したいため「Subversion」や「Git」を使いたいと声をあげるのですが、管理側からは
「膨大なCVSリポジトリを他のリポジトリに移行(変換)したとき、だれも品質を保証してくれない」
という理由でなかなか踏み切れないと聞いたことがあります。
この問題以外にもバージョン管理システムを切り替えるリスクは存在しています。
まずは新規プロジェクトで新しいバージョン管理サービスを利用して徐々に移行することをオススメしています。
今回は、初心者向けに「CVS リポジトリを別のリポジトリに移行する方法」「SVN/Git/Mercurial リポジトリを別のリポジトリに移行する方法」の記事を公開しました。
リポジトリの変換用のツールも提供されており比較的簡単に移行できることがおわかりだと思います。
エンタープライズ向けの大規模なリポジトリの移行サービスを行っておりますのでまずはこちらよりご相談ください。
移行先リポジトリ | ||||
---|---|---|---|---|
移行元リポジトリ | CVS | SVN | Git | Hg |
CVS | n/a | cvs2svn 一括変換 低 |
cvs2git 一括変換 低 |
hg convert 逐次変換 高 |
SVN | manual 手動変換 無 |
n/a | git-svn 一括変換 中 |
hg convert 逐次変換 低 |
Git | manual 手動変換 無 |
manual 手動変換 無 |
n/a | hg convert 逐次変換 低 |
Hg | manual 手動変換 無 |
manual 手動変換 無 |
manual 手動変換 無 |
n/a |
表中の各項目は、上から順に使用するコマンド、変換方法、難易度を表しています。
コマンド | cvs2svn | CVS→SVNリポジトリ変換コマンド |
---|---|---|
cvs2git | CVS→Gitリポジトリ変換コマンド | |
git-svn | SVN→Gitリポジトリ変換コマンド | |
hg convert | Mercurial拡張コマンド | |
manual | 移行元、移行先のバージョン管理ソフトウエアのcheckout/importコマンド | |
変換方法 | 一括変換 | 移行元のリポジトリを全て一括変換できる。 |
逐次変換 | 移行元のリポジトリを個別に変換できる。 | |
手動変換 | 移行元のリポジトリをチェックアウトして、移行先にインポートする。 | |
難易度 | 低 | 簡単に変換できる。 |
中 | 少し手間が掛かるが、変換できる。 | |
高 | 変換が不安定なことが多い。 |
詳しい説明は以下のサイトで説明していますのでご覧下さい。「CVS リポジトリを別のリポジトリに移行する方法」「SVN/Git/Mercurial リポジトリを別のリポジトリに移行する方法」
こんにちは、tracpath の重要な機能にソースコードの構成管理(バージョン管理)機能があります。
tracpath のバージョン管理機能は、Subversion(SVN) / Git / Mercurial を利用する事が出来ます。
あなたのチームでバージョン管理ソフトウェアを利用されている方もこれから利用を検討している方も参考になる記事を公開しました。
バージョン管理の歴史はそれなりに古く、RCS(Rivision Control System)が1982年に登場してから、30年余りが経過しています。オープンソースソフトウエア(OSS)の Apache Project や、FreeBSD Project などを中心にさまざまなバージョン管理ソフトウエアが開発されています。ソースコード管理に最適なバージョン管理ソフトウエアとして有名なソフトウェアのインストールから基本的な使い方を説明しています。
エンタープライズでもよく利用される4つのバージョン管理システムについてインストールから基本的な使い方を説明しています。自分にとって使い易いツールを見つけてください。
あなたのソフトウェア開発にとって必ず必要なバージョン管理システムの理解になればと思います。
項目 | 説明 |
---|---|
開発元 | The CVS Team |
最新版 | 1.11.23 / 2008年5月8日 |
最新評価版 | 1.12.13 / 2006年7月26日 |
プログラミング言語 | C |
対応OS | UNIX系、Windows |
種別 | バージョン管理システム |
ライセンス | GPL |
公式サイト | http://www.nongnu.org/cvs |
ref:WikipediaのCVS
項目 | 説明 |
---|---|
開発元 | Apacheソフトウェア財団 |
初版 | 2000年10月20日(13年前) |
最新版 | 1.8.1 / 2013年07月24日(4か月前) |
対応OS | クロスプラットフォーム |
種別 | バージョン管理システム |
ライセンス | Apache License |
公式サイト | subversion.apache.org |
ref:Wikipedia:Apache Subversion
項目 | 説明 |
---|---|
開発元 | 濱野純, リーナス・トーバルズ, ほか多数 |
初版 | 2005年12月21日(7年前) |
最新版 | 1.8.4.3 – 2013年11月8日 |
プログラミング言語 | C, Bourne Shell, Tcl, Perl |
対応OS | Unix系, Linux, Windows |
種別 | バージョン管理システム |
ライセンス | GNU General Public License バージョン2 |
公式サイト | git-scm.com |
ref:Wikipedia:Git
項目 | 説明 |
開発元 | Matt Mackall |
初版 | 2005年04月19日(8年前) |
最新版 | 2.8 / 2013年11月1日(36日前) |
プログラミング言語 | Python, C |
対応OS | クロスプラットフォーム |
種別 | バージョン管理システム |
ライセンス | GPL v2 |
公式サイト | mercurial.selenic.com |
こんにちは、以前「[git] クローンからプルしてマージ、コミットしてプッシュする」分散バージョン管理がはじめての方に向けて、Git(ギット)の基本学習用チュートリアルを公開しました。
読んで頂いた方々からいろいろな要望を頂きました。
その中でも多くの方が Windows 環境で利用できる GUI クライアントツールの解説がほしい。という要望です。
Git の基礎勉強はコマンドベース(CUI)である Git をつかったバージョン管理の考え方と使い方を理解してもらうために作成しました。
バージョン管理の基礎を理解している人たちに向けて Windows 環境で利用できる GUI ツールのチュートリアルを作成しましたので公開します。
Git Extensions の基礎勉強 ~ Git Extensions によるバージョン管理 ~
Windows にて Git を使いたい方におすすめする Git Extensions のチュートリアルです。
tracpath によるプロジェクト管理は、ガントチャートやWBSなどの管理者向けに開発されたツールではありません。開発チームにとって生産性向上と効率化するための仕組みを持った開発現場のためのツールです。
そのため、予算の管理、人材管理のための機能はありません。しかし、開発者や開発チームに必要なプロジェクト管理機能とソースコード管理があります。
大小を問わず、すべての開発チームに必須なツール
tracpath の強みである「課題がソースコードと連携していること」のメリットを説明します。
メリットは3つあります。
tracpath はあなたのプロジェクトの過去と現在の「なぜ」を理解するのに役立ちます。
以前に解決したバグに関連したファイルに作成された特定の変更を瞬時に見つけることが出来ます。これはプロジェクトの過去、現在含めすべての期間においてソースコードレベルで追跡することが出来ることを意味します。
プロジェクトの開始時点から現在までをタイムマシーンをつかって過去に移動することや特定の1地点だけを戻すことができます。
ソースコードをバージョン管理し、いつでも前のバージョンに戻すことが出来る安心感をあなたのチームに提供することが出来ます。
プロジェクトの開発状況をリアルタイムに知ることが出来ます。開発状況を把握し、必要ならタスク・課題あるいはチェンジセット(コミットログ)を閲覧することが出来ます。
ソースコードのバージョン管理システム用に開発された tracpath リポジトリビューアーでは
が統合された機能として提供しています。
バージョン管理システムのクライアントツールを使わなくても、またコマンドを覚えなくても、ブラウザのみで同様の情報を取得することが出来ます。だれでも、簡単に利用できる機能を提供することで開発者以外のチームメンバーにも価値ある情報を共有することが出来ます。
さらに詳しく説明してます。「ブラウザでソースコードの変更履歴を管理する「リポジトリブラウザ」機能」をご覧下さい。
開発チームはソフトウェア開発に必要な多くのアプリケーションを利用します。アプリケーションの切替を最小限にすることは、時間の節約と思考の切替によるロスを大きく削減します。
tracpath はコミットフックに対応しています。コミットフックによって開発者は簡単な構文をコミットログにメッセージとして追加するだけでワークフロー上のアクションを実行すること出来ます。
$svn commit -m "fixes #40 に対応しました。" や $git commit -a -m "fixed #41 に対応した"
こんにちは、以前「[git] クローンからプルしてマージ、コミットしてプッシュする」分散バージョン管理がはじめての方に向けて、Git(ギット)の基本学習用チュートリアルを公開しました。
読んで頂いた方々からいろいろな要望を頂きました。
その中でも多くの方が Windows 環境で利用できる GUI クライアントツールの解説がほしい。という要望です。
Git の基礎勉強はコマンドベース(CUI)である Git をつかったバージョン管理の考え方と使い方を理解してもらうために作成しました。
バージョン管理の基礎を理解している人たちに向けて Windows 環境で利用できる GUI ツールのチュートリアルを作成しましたので公開します。
TortoiseGit の基礎勉強 ~ TortoiseGit によるバージョン管理 ~
Windows にて Git を使いたい方におすすめする TortoiseGit のチュートリアルです。
すべてのプロジェクトで必ずやっておくべき大切なことがある。それはプロジェクトのビジョンを共有することである。新サービスの開発プロジェクトやパッケージのバージョンアップ開発プロジェクト、顧客向けフルスクラッチのシステム開発などすべてでやるべき仕事である。
プロジェクトのビジョンを共有する必要がある人たちは、プロジェクトに関わる全ての登場人物であり、開発者、顧客・経営者、管理者である。プロジェクトのビジョンを文書として作成することで、このプロジェクトでチームが重視しようとしていることや目指していること、顧客の重視していることや優先順位がまとめられ、プロジェクトのビジョンとして共有される。このビジョンを確立して共有するときに関係者内の利害関係や力の関係でたくさんの意見が出るかもしれない。
関係者に共有することが思いの外難しく時間がかかるかもしれない。
でも、この工程はとても重要なので今使う時間はプロジェクトが佳境に入ったときに使う時間と同じくらい大切である。このビジョンはプロジェクト計画立案や要件定義等の工程でその土台になるべき重要な要素と考える。
私たちがプロジェクトのビジョンを策定するときのフォーマットは以下のようなタイトルが並ぶ。
これを雛形にして、プロジェクト管理者が作成するようにしている。
== ○○プロジェクトのビジョン 1. 目的 2. 要件 3. 目標 4. プロジェクトの進め方 5. 予算・リソース・工数・スケジュール感
はじめにプロジェクトの背景や必要とされる理由が説明されるべきであり、プロジェクトをチームで進めていくためのベースの考えとして共有される目的を明示する。これによりチームは積極的な参加と正しいと思われる方向性を示すことがある。プロジェクトマネージャーが共感しやすい目的やビジョンを説明出来ることは、プロジェクトの価値を関係者に周知する強力なツールとなり、価値ある仕事と言うことを思い出させてくれる。
これまでプロジェクトのビジョン策定後、自分のチームに説明し顧客に説明することで、顧客自身がプロジェクトで達成したいこと、何を求めているのか、がはっきりすることが多々あった。
要件はプロジェクトに課せられることであり、顧客やチームが重視すべきことをまとめる。重視すべき点として予算内に収まるようにすべきか(コスト)、来年の2月までにサービスインすることか(期限)、現場の全ての声に対応した機能か、これらが複数定義されているか、を明示する。
私たちは箇条書きで思いつく要件を書き出し、優先度が高いと思われるリストに並び替えて整理したりする。
目標はプロジェクトで達成したいことーー自分たちのチームがこのプロジェクトを進める上で達成したいことーーを書いておく。
顧客の目的とは関係ない場合もある点を頭に入れておくべきである。
具体的な例として、すでに稼働しているシステムのバージョンアッププロジェクトでは「過去のコードのリファクタリングによるコードの最適化」「DBライブラリのバージョンアップ、チューニング」「Webアプリケーション用フレームワークのチューニング」などがある。その他にも「ペアプログラミングを実践」「コードレビューによるコードの品質を担保する」「テストの自動化ツールをプロジェクトに導入」などがある。
プロジェクトマネージャーを中心にプロジェクトのビジョンが策定され、成果物として必要なことが見えてくる。プロジェクトの進め方では、今回のプロジェクトにおいて最適と思われる開発方法ーーアジャイル開発?ウォーターフォール?ーーやチーム体制、責任の範囲、役割分担などが見えてくる。
自分のチームが得意としている方法・体制を明示する。
必須ではないがチームで共有できる場合、プロジェクトの予算、人的リソースーーだれが参加するのかーー、全体のスケジュール感(詳細なスケジュールはこれから計画されるはずであるが、おおよそのスケジュール感)を共有することは大切なことである。
プロジェクトのビジョンはプロジェクト計画前に作っておくことをオススメする。プロジェクトが始まる前にマネージャーが時間を確保し作成することでプロジェクト管理の指針になる。
このプロジェクトのビジョンはプロジェクトが進行中も更新されチームメンバーに共有される。
当社ではいつでも見られるようにtracpathのWikiによりメンテナンスされている。