概要表示の使い方

Sider Labs の解析結果の画面(ダッシュボード)では、様々な方法でコードクローンの分析を行うことができますが、この記事では「概要」タブにおけるコードクローンの可視化機能について使い方を説明します。 概要タブにはクローンの可視化パネルがあります。ホイール表示は、プロジェクトの全ファイルのうち、コードクローンが存在するファイルのみを抽出し、同一のクローンを持つファイル間の関係を図示したものです。プロジェクトのファイルが円環に沿って表示されています。円環を繋ぐように飛んでいる円弧が2つのファイル間に存在するクローンになります。円弧の幅がクローンのステートメント数に対応しており、円弧をクリックすると、実際のクローンのコードを閲覧できます。一方で、同一ファイル内部のクローンは円環のうえの「コブ」として表現されています。もし、ある程度大きな幅で、異なる2つのファイル間にまたがる円弧が表示されていたら、クローンの内容を確認することをお薦めします。ユーティリティ関数やクラスとしてまとめることで、コード品質をあげられるかもしれません。 ホイール表示の例 例えば上図はある3D画像処理のオープンソースソフトウェアのレポジトリを分析したものですが、"vmStackedVolume.cpp"(黄色)と、"vmBlockVolume.cpp"(ピンク)との間には、ステートメント数が30 から150程度のクローンペアが10個以上検出されており(図中右下の赤い点線部)、ファイルの名称も近いことから何らかの形で共通化できる余地がありそうです。 非常に大規模なプロジェクトの場合、ファイル相関図のファイル名や表示がほとんど見えなくなってしまうことがあります。今後、UI/UXの改善を行っていく予定ですが、ホイール表示の円環にマウスオーバーすると全ファイル名が表示されます。また、図の右上の「拡大」ボタンで図を拡大することもできます。「重要度トップ10」や「クローン数トップ10」のファイルのみで描画することもできます。ご活用下さい。

Continue Reading 概要表示の使い方

成功への分岐点 — ソフトウェアブランチのベストプラクティス —

ソフトウェア開発チームは、迅速に行動しなければなりません。予算はますます厳しくなっています。タイムラインも短くなってきています。そして、クライアントは常により多くの機能を求めてきます。もしあなたのチームが最大限の能力を発揮できるようにしたいのであれば、可能な限り効率的に仕事をする必要があります。 ソフトウェア開発チームにとって、ブランチの作成方法は生産性に関わる一要素ですが、いわゆるベストプラクティスを採用してないケースも多いようです。結果として、多くの問題や余計な労力が発生している可能性があります。この記事では、生産性を向上させる9つの方法を紹介します。 0.ブランチとは何ですか? ブランチとは、バージョン管理システム(Version Control System: VCS)で管理されているオブジェクトのコピーのことです。VCS内のコードベースは別名トランク(幹) とも呼ばれ、そこから異なる「ブランチ(枝)」が分岐しています。これらのブランチによって、ソフトウェア開発者は、コードベースを不安定化させることなく、分離して実験することができます。大規模なプロジェクトでは、開発者や品質保証など、多くの異なる役割が必要になります。ブランチを使うことで、これらの異なる役割を満たし、並行して開発することができます。一人の人間がブランチに変更を加えても、他のチームメンバーに影響を与えることはありません。 ブランチの利点は、多くの異なる人々が同時にプロジェクトに取り組むことができるということですが、ソフトウェアのブランチ化のベストプラクティスを持っていない場合、これは大きな頭痛の種になる可能性があります。 以下では、9つのベストプラクティスを紹介します。 1.ブランチング戦略をチームに伝える まず、どのようなブランチング戦略を採用するかを決める必要があります。ソフトウェアチームが利用するブランチング戦略で、広く採用されているものは以下の3つです。 Git Flow はおそらく最もよく知られている戦略です。2010年に策定されたこの戦略では、master が本番用ブランチであり、develop がベースブランチとして扱われるとしています。feature-*、hotfix-*、release-*など、さまざまなサポートブランチを使用することもできます。Git Flow は非常に厳格なプロセスを作成しますが、これはマージやリリースにおける心理的な不安を和らげるのに役立つかもしれません。もしあなたのQAプロセスが厳格なものであれば、Git Flowはあなたにとって最高のブランチング戦略となるかもしれません。 コインの裏返しになりますが、Git Flowは開発が本番と同等ではないため、環境間の移行が必須になります。そのため、頻繁なリリースを行う継続的デリバリー(CD)や継続的インテグレーション(CI)は、Git Flowの下では困難になる可能性があります。また、Gitの履歴が読めなくなることもしばしばあります。 https://www.nicoespeon.com/en/2013/08/which-git-workflow-for-my-project/ より転載 GitHub Flowは、Git Flowに比べてプロセスがはるかに簡素化されており、複数の異なる環境や同時バージョンの管理を必要としない小規模なチームにとっては、優れた選択肢となります。GitHub Flowでは、まずマスターブランチから始めます。作業が必要になるたびに、新しいブランチをチェックアウトします。作業内容を確認してマージする準備ができたら、master へのプルリクエストを開くだけです。マージされてmasterにプッシュされたら、理想的にはすぐにデプロイするべきです。…

Continue Reading 成功への分岐点 — ソフトウェアブランチのベストプラクティス —
ソフトウェアメトリクス2:ソースコードの規模
Carpenter holding a measure tape on the work bench

ソフトウェアメトリクス2:ソースコードの規模

いまさら Lines-of-code?   ソースコードの規模を測定する際に、最もよく使われるメトリクスはコード行数、いわゆるLines-of-code (LOC) でしょう。古くからあるメトリクスである上に、計測も簡単にできます。Linux 環境であれば、wc -l コマンド一発ですし、エディタで常時表示させることもできます。  ただし、ご存知とおりLOC は取り扱いが難しいメトリクスでもあります。特に、LOC を作業量の見積もりや、開発チームのパフォーマンスの計測に使う場合は、使い方を誤ると批判が生まれます。例えば、2つの異なるチームが「オンラインでの支払いシステム」を開発した時に、同じ期間で1000行のコードで開発したのと、100行のコードで開発したのでは、どちらのチームがパフォーマンスがよいと言えるでしょうか。ほぼ同じ機能であるならば、開発時のコストはもちろん、その後の保守メンテナンスのことも考えれば、より少ない行数で実現できた方がよいことは疑いようがありません。最近のNo Code の流行にもあるように、全くコードを書かずに実現できれば、それが最も効率が良いとも言えます。  LOC の問題点の一つは、単純な変数の代入も、複雑な算術演算ステートメントも、同じ1行でカウントされてしまうことにあります。この問題点を解決する一つのアイディアは、行の複雑度に応じて重み付けをすることですが、「17行目のステートメントが45行目のステートメントよりも2倍の重みを持っている」などと定量的に表現することは容易ではありません。LOC は、その名の通り単位「コードの行数」を数えただけのものであり、開発時間や、生産性や、コストに直接変換できるものではありません。  このように、様々な問題をもつメトリクスではありますが、それでもなおLOC が有用な場面は多数あります。例えば、LOCの絶対量ではなく相対的な変化に注目してチームの開発フェーズの変化を知ることができます。前述の通り、LOCの値そのものはチームの生産性と必ずしも関連性があるとは言えませんが、同じプロジェクト、同じチームにおいて、チームの先週のLOCと今週のLOC を比較することで、増加傾向であれば「設計フェーズから実装フェーズに入った」とか、減少傾向であれば「実装が一段落してテストフェーズに入った」などと類推することができます。  他には、LOC はテストや保守の基準値として使われることもあります。10万行のソフトウェアは、1万行のソフトウェアよりも保守やテストのコストがかかるのは同意できるところだと思います。バグの数をLOC で割ったものを「バグ密度」と定義し、ソフトウェア品質の基準値として使っているチームもあります。  LOCの計測方法にはいくつかの定義があり、チームや組織で採用する場合は同じ定義を一貫して使うことが重要です。単純にテキストファイルとしての行数(Physical LOC)を使うこともありますが、多くの場合、空行とコメント行を除いた行数(Non-comment LOC: NLOC)や、NLOCからさらに、「2つの命令が書かれた行は2行と数える」、「括弧だけの行を除く」などの換算をした行数(Logical LOC: LLOC)を用いることが多いでしょう。コメントの行数をComment lines of…

Continue Reading ソフトウェアメトリクス2:ソースコードの規模
ソースコードレビューツールとは?代表的ツール7種をご紹介
Software engineers people working on project and programming in company

ソースコードレビューツールとは?代表的ツール7種をご紹介

 ソースコードレビューは、近年のソフトウェア開発プロセスに不可欠な要素ですが、リリース時期が迫りメンバーが多忙になると、十分にコードの確認ができなかったり、レビュー自体がスキップされてしまうことも起こりがちです。そのような忙しい場合でも品質を一定に保つためには、レビューの効率を上げる必要があります。この記事では、コードレビューの効率を上げるために、現在(2020年)広く導入されているコードレビューツールを7つご紹介します。 ソースコードレビューとは?  ソースコードレビューが行われるタイミングは様々です。ソースコードマネージメントツールとしてGitHubやGitLab を利用している場合は、最も一般的なコードレビューのタイミングはPull Request (GitLab の場合Mearge Request) のタイミングでしょう。組み込み系開発などでは、ある程度まとまった単位でのコードを、メンバー全員で時間をかけてレビューするやり方もあります。コードレビューを行う主たる目的は以下のとおりです。 不具合の発見: マルウェア、バグ、パフォーマンスの問題、セキュリティホールなど、コードの欠陥を見つけることは、コードレビューの最もな重要な要素です。 コード品質の向上: ソースコード単体の不具合を見つけるだけではなく、プロジェクト全体の品質を改善します。「機能している」からといって、改善する箇所がないわけではありません。コードレビューによってリファクタリングが必要な箇所がみつかることもあるでしょう。 学習・ナレッジシェア:  新人開発者や品質保証エンジニアは、コードレビュープロセスを導入することで、開発者の意図を学ぶことができ、スキルアップにもつながります。また、チームの誰かがなんらかの理由で抜けることになっても、他のメンバーがバックアップ可能になります。 連帯感の向上: コードレビューは、チームワーク、責任感、コミュニティの形成に役立ちます。 コードレビューツール7選  今日の市場には数十種類ものコードレビューツールが存在し、その中から組織のニーズに最適なものを選ぶのは難しいでしょう。以下では、汎用性が高くかつ堅牢なコードレビューツールを紹介します。 GitHub GitHubはプルリクエストの画面にコードレビューツールが付属しています。すでにGitHubを使ってGitレポジトリをクラウドで管理している場合、プルリクエストを使ってコードをレビューするのはもはやあたりまえになっているかもしれません。無料でも利用可能ですが、保持できるデータ量や月ごとに行えるアクション数に制限があるため、チームや企業で利用する場合は有料のオプションを選択することになるでしょう。 GitHubでは、レポジトリへのアクセス権を持つメンバーをプルリクエスト毎にレビュアーとして割り当てることができます。プルリクエストを提出した開発者は、管理者にコードレビューを依頼することもできます。変更履歴の確認だけでなく、プルリクエストの議論やdiffの分析、インラインでのコメントも可能です。コードレビューツールでは、GitにおけるコンフリクトをWebインターフェイスで解決することもできます。さらに、マーケットプレイスを通じて追加のレビューツールと統合することで、レビュープロセスの機能を拡張することもできます。 GitHub付属のコードレビューツールは、あなたの組織がすでにGitHubを利用している場合には最適なツールです。すべてが組み込まれているので、追加のインストールや設定は必要ありません。 Review Board Review Board は、このWebベースのオープンソースのコードレビューツールです。コードレビューとドキュメントレビューの両方が利用可能で、コード比較をグラフィカルに表示することができます。ウェブサイトでデモ版を試すこともできるし、ソフトウェアをダウンロードして自分のサーバーにセットアップすることもできます。Review Board の初期バージョンはかなり前にリリースされたものですが、依然として活発な開発が行われています。…

Continue Reading ソースコードレビューツールとは?代表的ツール7種をご紹介

ソフトウェア開発において最も重要なメトリクスは何か?

メトリクス(評価指標) の測定は、ソフトウェア開発チームとマネージャーが製品の品質を高め作業の効率を上げるのに役立ちますが、プロジェクトや組織に合った適切なメトリクスを選択することが重要です。 この記事では、ソフトウェア開発メトリクスが重要である理由、プロジェクトとチームにとって最も効果的なメトリクスを選択する方法、そして広く採用されている代表的なメトリクスについて紹介します。 1. 適切なメトリクスを選択する方法 情報は、定量化することでより便利に使えるようになります。データを集計・測定することで、どのような時間と労力の投資が実際に成果を上げているか、そしてどのようにプロセスを改善するべきかを判断することができます。 ソフトウェア開発チームとそのマネージャーは、メトリクスを基準を用いて作業において何が重要であるかを測定し、その測定結果を基にチームの目標を設定し、メトリクスの時系列変化を観察します。ソフトウェア開発メトリクスを使って、ソフトウェア開発プロジェクトの成功に不可欠な生産性、効率、品質、およびその他のKPI(Key Performance Indicator) を測定することができます。 しかし、情報と測定量は多ければよいとは限りません。ソフトウェア開発プロジェクトによって生成されるデジタルデータの量を考えると、チームにとって情報が多すぎるという問題を抱えないようにすることが重要な課題です。どのソフトウェア開発メトリクスを使うかを慎重に検討し、チームの成功をもらたすメトリクスを選択し測定する必要があります。 また、一部のソフトウェア開発チーム、特にアジャイル方法論や他のリーン・プロセスフレームワークを採用しているチームの中には、メトリクスの使用に抵抗を感じるチームもあるでしょう。データの収集と測定というあまり生産的でない作業に多くの時間を費やしたくないためです。チームがメトリクスのための作業でつまづいたり、「バニティメトリクス(Vanity Metrics: サービス改善につながらない指標、意味のない指標)」に夢中になり時間をかけすぎるような場合、製品の質も士気も低下してしまう可能性があります。 そのため、選択したメトリクスで得た情報を理解し、それによりプロジェクトの状況を決定し、時間リソースの最適化ができるかどうかを常に確認してください。 定期的にメトリクスを見直し、チームにとって引き続き有効かどうかを判断します。もし以前選択したメトリクスが役に立たなくなっていると感じたら使うのをやめ、代わりに新しいメトリクスを試してください。 2. ソフトウェア開発メトリクスの分類 開発中の製品は、順調に完成に向かっていますか? あなたのチームはどれだけうまく仕事を進めていますか? そのような質問に答えるためのソフトウェア開発メトリクスは、大きく分けて2つのカテゴリに分類されます。 デリバリー・メトリクス:スプリントの効率、プロジェクトのデリバリーまでのリードタイム、および、チームが作業を完了するまでの時間を左右するその他の要因を測定します。 これらのメトリクスは顧客満足度に影響を与えます。また、マネージャーはこれらのメトリクスを使用して、製品のリリース時期と内容を決定することができます。 テクニカル・メトリクス:コードベースのソフトウェア開発メトリクスは、技術的な観点からのプロジェクトの堅牢性を測定するもので、製品を内部レベルで分析し、製品のパフォーマンスを把握するのに役立ちます。 バグ、セキュリティなどの要因は、このテクニカル・メトリクスを使用して測定されます。 通常これらのメトリクスは、ツール等を利用して自動的に測定されるようにします。 開発チームのリーダーと協力して、自動計測をどのように実装するのが最善か、検討してみましょう。 上記を踏まえて、どのメトリクスを選択するかはあなた次第です。 さまざまなソフトウェア開発チームのリーダーが、過去の経験則に基づいてメトリクスやその計測システムを選択しています。 選択するメトリクスは、その企業固有の価値観を反映している場合もあれば、チームが現在使用している一般的なフレームワークの一部である場合もあります。…

Continue Reading ソフトウェア開発において最も重要なメトリクスは何か?
リファクタリングはじめの1歩 — 手法や注意点を初心者向けに解説 —
Group of young programmers developing data code, working together in modern office, panorama with free space

リファクタリングはじめの1歩 — 手法や注意点を初心者向けに解説 —

リファクタリングとは?  プロのソフトウェア開発者はほぼ全員知っているが、学生やアマチュアの開発者はあまり知らない用語として、真っ先に思いつくものの一つが「リファクタリング」ではないでしょうか。  アマチュアの開発者は、多くの場合自分のためだけにコードを書きます。コードは論文発表のためだったり、自分の作りたい実験的なシステムのためだったり、目的は様々ですが、基本的には期限付きのもので必要な時にある程度動作すればそれでよく、目的を果たした後はそのまま放置されることがほとんどでしょう。一方、プロの開発者は、チームで作業を行うことがほとんどです。プロジェクトの存続期間も長く、製品を完成させた後も、機能追加・機能改善など引き続き作業が発生します。そのため、 他人が読んで理解しやすい変更がしやすいバグが生まれにくい など、いわゆる「品質の高い」コードであるかどうかは非常に重要なポイントになります。  リファクタリングは、ソースコードの品質を向上させる手法の一つです。リファクタリングの教科書ともいえる名著「リファクタリング(第2版): 既存のコードを安全に改善する」での定義を引用すれば、 リファクタリングとは、ソフトウェアの外部の振る舞いを保ったままで、内部の構造を改善していく作業 を指します。具体的には、様々な理由で設計が劣化し、可読性が低下してしまったソースコードを、機能毎に切り分けてクラス化・関数化したり、逆に同じ処理をまとめてクラス化・関数化したり、変数や関数名をわかりやすいものに変えたり、様々な手法を用いて人間にとって理解しやすいコードに置き換えます。この際、ソフトウェアを使うユーザー側から見える挙動は変わっていません(厳密には、処理速度が速くなったり遅くなったりすることがあるかもしれませんが、それが許容できるか、あるいは思わぬプラスの効果になるかはシステムによります)。 リファクタリングにより、以下のようなメリットが得られます。 全体的な開発スピードの向上リファクタリングにより設計が改善されると、各モジュールの影響範囲が明確になります。これにより、例えば新規機能開発の際に、どこをどのように変更すればいいか、容易に理解することができ、開発スピードが上がります。 潜在的なバグの顕在化リファクタリングの作業にはバク修正は含まれていませんが、リファクタリング作業自体を通して、そのソースコードの深く理解することができます。最終的に設計やコードをわかりやすくした結果として、いままで気が付かなかったバグが発見されることがあります。 チームとしてのパフォーマンス向上前述のとおり、多くのソフトウェア開発プロジェクトはチーム戦です。自分の書いたコードを他のメンバーがデバックすることもあるでしょう。リファクタリングを行い定常的に可読性を高めておくことは、むしろ自分以外の各メンバーにとってメリットが大きいといえます。また、新しく加わるメンバーにとっても、コードの理解が容易であれば、戦力になるまでのキャッチアップの時間を最小限にできます。 逆にデメリットとしては、リファクタリングをしている間はユーザーが受ける価値は全く変わらない、ということが挙げられます。もっと悪いケースとして、リファクタリングのやり方によっては、せっかく正常に動作しているソフトウェアに手を加えることで、動作がおかしくなってしまうこともありえます。リファクタリングは、ある意味で将来への投資であり、今、ソースコードの品質を上げるコストを支払うことで、上に挙げた将来の開発上の様々なメリットを享受する行為と言えます。つまり、リファクタリングを行うか否かは、 現在の製品がユーザーに与えている価値製品の将来ロードマップリファクタリングにかかるコストリファクタリングにより、動作している製品を改修するリスク逆にリファクタリングしない場合の、将来のバグやトラブルのリスク などを総合的に分析して決断すべきでしょう。そのような決断をする際の判断材料のひとつととして、Sider Labs を使用いただければ幸いです。 リファクタリングの方法 この章ではリファクタリングの具体的なやり方について説明します。まず最初に準備することは、リファクタリング対象となるコードについての十分なテストコードを用意することです。「動いているものには触るな」という格言があるように、正常に動いているものに手を入れるのは怖いものです。加えた変更の影響範囲が把握できずに、意図せず別の箇所でバグを生んでしまうことは十分ありえます。そのため、テストコードを用意して動作を確認をしながら安全にリファクタリングを行うことが重要になります。  テストの作成には時間がかかりますが、コードとテストと、自分の実現したいことを2度書くこと自体が、バグを減らすことにつながります。また、GitHub, GitLab などのバージョン管理ツールを導入していない場合は必ず導入しましょう。もしなんらかの問題で、動作がおかしくなってしまっても、バージョン管理ツールで正常な状態にいつでも戻すことができます。  テストコードの準備ができたら、いよいよリファクタリングを行います。コードの可読性を上げる手法はいろいろあります。先に紹介した、「リファクタリング(第2版): 既存のコードを安全に改善する」では、リファクタリングの手法(How) が78種類ものパターンに分類されて、それぞれの典型的な手順がまとめられています。また、リファクタリングを始めるトリガー(When) となる「コードの不吉な臭い(英: Code Smell)」についても、24種類のパターンを示しています。ここでは、我々のSider Labs…

Continue Reading リファクタリングはじめの1歩 — 手法や注意点を初心者向けに解説 —

ソフトウェアメトリクス1: 循環的複雑度

 ソフトウェアの品質を測定するためのメトリクス(指標)はいろいろありますが、本記事ではソースコードの品質を評価する指標の一つ、循環的複雑度を取り上げたいと思います。1970年代に提唱されたメトリクスであり、現在のソフトウェア開発には合わないという意見もありますが、他の指標と合わせて使うことで依然として有用なメトリクスとなります。 循環的複雑度の定義  循環的複雑度(英: Cyclomatic Complexity) は、その名称から、単にプログラム内のループの個数を数えるものであると誤解されていることも多いですが、実際にはプログラムの構造を「制御フローグラフ(英: Control flow graph)」で表した際のグラフ内部の循環の数に着目してソフトウェアプログラムの複雑性を測定する指標です。1976年にMcCabe によって提案されました。ちなみに制御フローグラフとは、プログラムの実行中にプログラムを通過する可能性のあるすべての経路を有向グラフで表現したもので、Frances E. Allen によって提唱されたものです。  Fig 1 に制御フローグラフの例を示します。ここで、プログラムの開始位置をノード a, 終了位置をノード f とします。プログラム中の反復や条件分岐が開始する位置と終了する位置もそれぞれノードとなり、図の例ではノードb からe となっています。ノード間をつなぐ逐次処理の部分はエッジとなり矢印で表現されます。ちなみに、逐次処理部分は、プログラム行数が何行であっても(0行であっても) 1つのエッジとなります。 Fig 1: 制御フローグラフの例 (McCabe 1976 より転載) 循環的複雑度の定義は以下のとおりですV(G)…

Continue Reading ソフトウェアメトリクス1: 循環的複雑度

Gitホスティングサービスはオンプレミスとクラウド、どちらが主流か。GitHub GitLab BitBucketのオンプレ版紹介と日米事情

Gitホスティングサービスのオンプレミス版とクラウド版の違い Gitホスティングサービス・Gitプラットフォームサービスを使うのがGitでソースコードを管理する上では当たり前のようになってきました。サービスベンダーはクラウド版とオンプレミス版を提供していることが多く、企業は自社のセキュリティポリシーやベンダーに求めるサポートによってオンプレミス版とクラウド版を選択していることが多いでしょう。 各ベンダー・プラットフォームのそれぞれのオンプレミス版について紹介をさせていただきます。 GitHub Enterprise Server GitHub.com のオンプレミス版です。現在のGitHubのライセンスモデルではGitHub Enterpriseのライセンスを購入するとGitHub Enterprise Cloud(GH)とGitHub Enterprise Server(GHE)の両方が同一ライセンスで利用することが出来ます。 GitHub Enterprise ServerではGitHub.comの機能が一部使えないものがありますが、基本的には全ての機能が使えると思っていただいて差し支えないと思います。 GitHub Enterprise Serverで使えない機能がいつ使えるようになるかは下記のGitHub社が公開しているロードマップを御覧ください。 https://github.com/github/roadmap/projects/1?card_filter_query=label%3Aserver また、その他のベータ版の機能等についても同様のGitHub Projectで公開されています。 https://github.com/github/roadmap/projects/1 なおGHEの料金は$21 per user/monthとなっています。 月額決済はなく年額決済のみ・10人単位、など購入経路などによっても料金や体系が異なる可能性がありますのでぜひGitHub社、Microsoft社、代理店(マクニカネットワークス社など)などにお問い合わせください。 https://github.com/pricing https://www.macnica.net/github/index.html/ GHEはクラスタリングをサポートしており、大人数での利用も可能です。…

Continue Reading Gitホスティングサービスはオンプレミスとクラウド、どちらが主流か。GitHub GitLab BitBucketのオンプレ版紹介と日米事情

GitLabは最新版を使おう!GitLabのバージョンポリシーとアップグレードの方法

当ブログでは以前GitLabのインストールに関する記事を書かせていただきましたが、今回はその運用にあたって、「バージョンアップ」関連についてです。 前回のインストールについてはこちらをご覧ください。 https://developerex.jp/gitlab-ee-quick-start-guide-within-10min/ GitLabのバージョンポリシー GitLabはセマンティックバージョニングによるリリースを採用しています。そのため、アップグレードはメジャーバージョン、マイナーバージョン、パッチバージョンの3段階で行われます。 参考: GitLab release and maintenance policy https://docs.gitlab.com/ee/policy/maintenance.html また、上記サイトにてサポート(パッチが提供されるバージョン)ポリシーについては下記のように記載されています。 > Backporting bug fixes for only the current stable release at any given time. (See patch releases.)…

Continue Reading GitLabは最新版を使おう!GitLabのバージョンポリシーとアップグレードの方法

GitとGitプラットフォームについてと、GitHubかGitLabかBitBucketの3大Gitプラットフォーム紹介

Gitについて 2020年現在、ソースコード管理システムとしてはおそらく最も使われているのはGitです。GitはLinuxの開発者でもあるLinus Benedict Torvalds氏により開発され2005年に登場しました。当時はCVSやSVNやが主流でしたが、開発者個々人が細かな変更履歴も含めて管理(記録・追跡)が行えるバージョン管理システムとしてGitが使われるようになってきました。 その後、Gitのプラットフォーム、特にGitHub.comの登場とオープンソースソフトウェアの開発コミュニティのGitHubへの移行に伴いGitの普及速度がますます伸び、現在ではデファクトのバージョン管理システムであると言っても過言ではない普及率になっているかと思います。 Gitプラットフォームのメリット 2010年頃の日本では公式(標準)のGit を自社のサーバー上で稼働させているケースも多くありました。一方で、Gitサーバーの運用コストも低くはなく、より利便性の高い、クラウドで動作するGitプラットフォームサービス、GitHubやBitBucket、GitLabなどがその後大きく普及し、2020年現在では、Gitサーバー単体の利用や運用ではなく上述のものを利用しているチームが殆どを占めているように思います。 Gitサーバー単体ではソースコードを管理することが出来るのみで、UIなどはなく、コードレビューの機能なども備えていません。コマンドラインからGitサーバーのURLに対してブランチ(メインブランチから派生したトピックブランチ、もしくはメインブランチのソースコード)をPushして保管することが出来るのみです。 Gitサーバーの運用を簡単にするのに加えて、UIなどの様々な機能を追加したものがGitプラットフォームです。 プラットフォームを利用するメリットとして特に次の3つがどのプラットフォームでも共通して言えるものであり、大きいメリットでしょう。 ソースコードのコラボレーション開発・コードレビュー機能(Pull Request、Merge Request) WebUIで様々ながことが行える高いユーザビリティ チケット管理機能などの開発に関わる重要な付随機能やそういった機能・サードパティサービスとの連携機能 ソースコードのコラボレーション開発・コードレビュー機能(Pull Request、Merge Request) Gitではメインブランチとは別にトピックブランチなどで開発をし、メインブランチにPull Request(or Merge Request)を作成、トピックブランチでの開発内容をメインブランチに取り込むことによって、ノンリニア開発(数千の並列ブランチでの開発)を実現します。 それに伴い非常に重要な役割を果たすのがにPull Request(or Merge Request)といった機能で、メインブランチとサブブランチの差分を表示し、また、それについて開発者同士でコメント等によりコミュニケーションを行いマージするかどうかの可否判断をすることができます。 業務でのソフトウェア開発やオープンソースソフトウェアの開発など、あらゆる種類のソフトウェアの開発でこの機能は利用されています。 WebUIで様々ながことが行える高いユーザビリティ Gitサーバー単体ではすべての操作がコマンドライン経由であり多くの方にとって難しい、利便性が低い、とっつきづらいものでしょう。その点、先述のGitプラットフォームはいずれもソースコードを簡単にに閲覧する事ができる、ファイルや行ごとにいつ誰がどのような理由(コミットメッセージ)でコミットしたか、などを容易に閲覧や検索が出来るなどの強力な機能、ユーザビリティが備わっています。…

Continue Reading GitとGitプラットフォームについてと、GitHubかGitLabかBitBucketの3大Gitプラットフォーム紹介