| FEATURES |  | |
| コミットグラフとレポートツール GitLabは共同作業に役立つ、コミットグラフとレポートツールを提供します。 | ||
| 包括的なインポート機能 GitLab は、GitHub や他の VCS よりも多くのソース (GitHub, Bitbucket, Google Code, FogBugz, Gitea, 任意の git URL) からプロジェクトと課題をインポートできます。また、SVNからGitへ移行するための包括的なガイドとドキュメントも用意されています。 | ||
| 議論をロック 不正使用、スパム、非生産的な議論を防止するため、管理者以上の権限を持つユーザーは議論の継続をロックすることができます。 | ||
| カスタム通知 課題やマージリクエストに変更があると、メールやSlackやTodoで通知できます。 | ||
| リンクホバーに関するリッチオブジェクトの概要 GitLab のユーザー、課題、マージリクエスト、その他のオブジェクトへのリンクにカーソルを合わせると、豊富な情報量の概要を表示されます。 | ||
| マージリクエストの承認を必須にする プロジェクトで複数の承認が必要な場合、マージ前にすべてのマージリクエストを承認する必要があります。 必要な承認の数を設定し、特定の承認者のリストを事前に定義することで、マージリクエストの承認を必須にすることができます。 これにより、コードの品質と標準への準拠を保証することができます。 | ||
| コードレビューを複数人で承認 GitLab では厳密なコードレビューを保証するために、マージリクエストをマージする前に、 マージリクエストに対して様々なユーザーからの特定の数の承認 を要求することができます。一度承認した後で問題に気がついた場合は、承認を取り消すこともできます。 | ||
| コードレビューの承認ルール 適格な承認者のリスト、それぞれの承認数の最小値、 およびどのターゲットブランチを保護するかを指定して、 承認ルールに沿って適切な人がマージリクエストをレビューするようにします。これにより、 エンジニアリング、UX、プロダクトといった異なるチームにレビューを依頼することが容易になります。 | ||
| 任意のマージリクエストの承認 良好な状態のマージリクエストを承認することは、レビュープロセスの重要な部分であり、変更をマージして良いことを明確に伝えることができます。 | ||
| フォークしたリポジトリの Git オブジェクトに関する重複排除 Gitオブジェクトをプールすることで、フォークされたGitリポジトリのディスクストレージ使用量を削減します。 | ||
| Wiki によるプロジェクトのドキュメント それぞれのプロジェクトのドキュメントを管理するためにWikiが使用できます。。すべてのWikiは独立したGitリポジトリとして利用できます | ||
| デザイン管理 デザイン管理では、ユーザーはデザインアセット（ワイヤーフレームやモックアップなど）を課題にアップロードし、それらを一箇所に保管しておくことができます。これにより、プロダクトデザイナー、マネージャー、エンジニアがシームレスにデザインのディスカッションを行うことができます。 これらのアセットは簡単にアップロードでき、バージョンごとに保管されます。 また、ディスカッションでフォーカスしたい場所の画像をクリックすると、スレッドを開始することができます。 | ||
| GitLab-Figmaプラグイン Figmaプラグインを使うと、GitLabの課題にFigmaのフレームやコンポーネントをアップロードすることができます。 | ||
| 画像に関する議論 コミット画面やマージリクエストの差分画面で、画像の特定の位置を指定して、画像に関する議論をコメントできます。1つの画像に対して複数の議論を作成できます。 | ||
| マージリクエストのコミットに関する議論 マージリクエストのコミットに対してコメントをすることができます。 | ||
| メールからマージリクエストを作成 マージリクエストのタイトル、説明、ソースのブランチ名を記載したメールを送信してマージリクエストを作成できます。あるいは、最初にブランチをプッシュせずにパッチファイルを用いてマージリクエストを作成します。 | ||
| 初回貢献者バッジ プロジェクトに初めて貢献する貢献者をハイライト表示します。 | ||
| レビューアプリで変更をプレビュー GitLab CI/CDを利用して、ブランチごとに新しい環境を作成することができ、開発プロセスを高速化できます。自分のブランチをプレビューできるマージリクエスト用の動的な環境を起動できます。レビューアプリは静的・動的なURLの両方をサポートします。 | ||
| 他のサービスから簡単に移行 以前に使用していたサービスから、すべてのリポジトリ、課題、マージリクエストのデータをGitLabへ簡単に移行できます。 | ||
| 曖昧ファイル検索でファイルを探す GitLabは少ないキー入力でリポジトリ内のファイルを探す方法を提供します。 | ||
| fast-forwardマージ、およびrebaseオプション マージコミットを作成せず、すべてのマージをfast-forwardとするように、プロジェクトレベルで設定できます。fast-forwardマージができない場合は、rebase後にマージするオプションを選択できます。 | ||
| squashしてマージ 複数のコミットを1つにまとめてからマージすることで、メインブランチの履歴をシンプルに保つことができます。 | ||
| GitLab.comからインポート GitLab.comからプライベートインスタンスにプロジェクトをインポートできます。 | ||
| プロジェクトのサイズをグローバル、グループ、プロジェクトレベルで制限 ディスク使用量を適切に制御することができます。 | ||
| マージリクエスト マージリクエストを作成してチームメンバーに@メンションすると、変更をレビューしてから安全にマージが行えます。 | ||
| マージの衝突を解決 マージの衝突をGitLabのUIでプレビューして、どちらのバージョンを使用するのか選択できます。 | ||
| 未署名コミットを拒否 GitLab Premiumでは未署名コミットのプッシュを拒否することで、GPG署名コミットを強制することができます。 | ||
| コミッターの検証 コミッターとプッシュの実行者が同一人物であることを検証できます。 | ||
| Gitでディスク使用量を削減 一般的に、Gitリポジトリのディスク使用量は、類似のSVNリポジトリのディスク使用量よりも少なくて済みます。 | ||
| ファイルのロック 複数人で同じファイルを使って作業をすることにはリスクが伴います。バイナリファイルで発生した衝突の解決には、 多大な労力が必要となります。 GitLab Premiumでは、特定のファイルやディレクトリ全体をロックすることで、 自分以外がバイナリファイルを編集することを防止することができ、 面倒なバイナリファイルの衝突を回避することができます。 | ||
| パイプラインの成功時にマージ レビューが済んでマージできる状態なのに、CI/CDのジョブが完了するまで待つ必要がある場合は、パイプラインが成功したら自動的にマージするように予約することができます。 | ||
| 特定のコミットやマージリクエストをUIから取り消し ボタンをクリックするだけで、コミットやマージリクエストの取り消しができます。 | ||
| 強力なブランチ機能 Git のブランチには、それに先行するすべての履歴が含まれています。 また、ブランチを作成、移動しても、即座に簡単に共有することができます。 | ||
| 保護ブランチ 保護ブランチに対して、きめ細かいアクセス制御ができます。 | ||
| Web IDE Web IDE を使用してローカル開発環境でのコンテキスト切り替えを回避することで、プロジェクトへの貢献を迅速にします。Web IDE はマージリクエストや GitLab CI と統合されているため、Web IDE を離れることなくフィードバックを解決、失敗したテストの修正、変更のプレビューをクライアント側の評価でライブ表示ができます。 | ||
| Web IDE でのライブプレビュー Web IDE のライブ プレビューを使用して、JavaScript と 静的なHTMLファイルのプロジェクトに加えた変更をプレビューできます。 | ||
| Web IDE の Web ターミナル Web IDE の Web ターミナルでコードを操作して、API 応答の検査、REPL の実験、コードのコンパイルを実行します。 | ||
| Web ターミナルへのファイル同期 Web IDE で行った変更が Web ターミナルに同期されるようになりました。Web IDE で行ったユーザーの変更を、 プロジェクトにコミットする前に Web ターミナル内でテストできるようになりました。 | ||
| Web IDEの設定 Web IDEは、プロジェクトで作業するすべてのユーザーのコーディングスタイルを標準化するために、プロジェクト内で `.editorconfig` ファイルを使用することをサポートしています。 これにより、プロジェクト全体での一貫性と品質を簡単に維持することができます。 | ||
| Web IDEのMarkdownに画像を貼り付ける Web IDEでMarkdownファイルを編集する際に、コンテンツに画像を貼り付けることができます。これにより、コンテンツ内で画像を自動的にアップロードし、参照できます。 | ||
| Real-time feedback for .gitlab-ci.yml in Web IDE To make it easier to configure your GitLab CI pipeline, the Web IDE now provides real-time linting and completion when editing `.gitlab-ci.yml` files. Learn more about .gitlab-ci.yml editing feedback in the Web IDE | ||
| スニペット 引用可能なコード片を、コードスニペットとして保存して共有できます。 また、1行のコードでブログやウェブサイトに埋め込むこともできます。 | ||
| バージョン管理されたスニペット Git ベースのスニペットを使って、オンラインでもローカルでも共同作業を行い、バージョン間の変更を追跡することができます。 | ||
| マージリクエストのバージョン ブランチにプッシュする毎に、マージリクエストのバージョンが作成されます。マージリクエストのUIで、バージョン間の差分を表示できます。 | ||
| インラインコメントと議論の解決 マージリクエストのインラインコメントを使用すると、コードやテキストのレビューがより高速かつ効果的になります。特定のコード行についてコメントを残し、議論を解決します。GitLab では、マージリクエストのインラインコメントは議論として解釈され、変更されてもされなくても任意の行に残すことができます。すべての議論が解決されたときにのみマージリクエストが承認されるようにプロジェクトを構成できます。 | ||
| 変更のcherry-pick マージリクエストや特定のコミット内のCherry-Pickボタンをクリックするだけで、あらゆるコミットをcherry-pickできます。 | ||
| アクティビティストリーム コミット、マージ、コメントなどプロジェクトのチームメンバーの直近の活動を一覧表示できます。 | ||
| GPG署名コミット 署名コミットを使用すると、特定のユーザーによってコミットされたことを証明できます。 | ||
| 仕掛中のマージリクエスト (WIP) 仕掛中のマージリクエストを間違えてマージすることができないように、マージリクエストを仕掛中(WIP)としてマークできます。これにより、仕掛中の変更であっても安心してレビューの依頼ができます。 | ||
| プッシュとマージを特定のユーザーに制限 保護ブランチの機能を拡張して、保護ブランチにプッシュとマージができるユーザーを選択できます。 | ||
| 保護タグ 保護タグに対して、きめ細かいアクセス制御ができます。 | ||
| 統合されたカスタムのプロジェクトテンプレート 新しいプロジェクトを作成するときは、いくつかの実用的なサンプルコードや CI が予め設定されている定義済みのテンプレートからプロジェクトを開始することができます。 さらに、グループを割り当ててカスタムのプロジェクトテンプレートを定義できます。このグループの子プロジェクトは、新しいプロジェクトを作成するときのテンプレートとして使用できます。 | ||
| 脆弱性管理 GitLab の脆弱性管理は、資産やアプリケーションの脆弱性スキャンを確実に行うためのもので 、脆弱性を記録、管理、緩和するプロセスも含まれています。 脆弱性管理は 、セキュリティ組織だけでなく、チーム全体で緩和、管理、対応が可能な、資産とアプリケーションコードの両方に存在する意味のある一連の脆弱性を特定するのに役立ちます。 また、~"devops::secure" ステージからの結果を管理するために、チームがすでに使用しているシステムと統一されたインターフェイスを 提供することで、セキュリティ結果を管理するための単一の信頼できる情報源として使用できます。 | ||
| Gitのプッシュでプロジェクトを作成 新しいプロジェクトを作成したい場所にプッシュすると、自動的に新しいプライベートプロジェクトが作成されます。 | ||
| プル/マージリクエストでパイプラインのステータスを表示 パイプライン実行のステータスと結果をマージ/プルリクエストで表示することができます。 | ||
| S/MIME Signed Commits 署名コミットを使用すると、特定のユーザーによってコミットされたことを証明できます。 |
このページのコンテンツ
概要
Across full lifecycle
Only SCM
Additional cost for private
Additional cost for private
Azure Container Registry
Azure Monitor
Azure Security Center
Azure Security Center
Azure Security Center
Azure Security Center
Azure Security Center
要約
On September 10, 2018 Microsoft renamed VSTS to Azure DevOps and by Q1 2019 will rename TFS to Azure DevOps Server, and upgrade both with the same new user interface.
Azure DevOps (VSTS) is a hosted cloud offering, and Azure DevOps Server (TFS), is an on-premises version. Both offer functionality that cover multiple stages of the DevOps lifecycle including planning tools, source code management (SCM), and CI/CD. However, first development focus will be to Azure DevOps (SaaS). Their project manager shared that they are releasing on a 3-4 week pace. This seems evident based on their published roadmap. The same project manager also shared that Azure DevOps Server (TFS) will be 3-4 months behind on adopting new features (also evident by their published roadmap). They are both from the same code base.
As part of their SCM functionality, both platforms offer two methods of version control.
-
Git (distributed) - each developer has a copy on their dev machine of the source repository including all branch and history information.
-
Team Foundation Version Control (TFVC), a centralized, client-server system - developers have only one version of each file on their dev machines. Historical data is maintained only on the server.
Microsoft recommends customers use Git for version control unless there is a specific need for centralized version control features. https://docs.microsoft.com/en-us/vsts/tfvc/comparison-git-tfvc
This is noteworthy given that in June of 2018 Microsoft purchased GitHub, the Internets largest online code repository. This deal closed Oct 26th, 2018.
Breakdown
Because the Azure DevOps suite is so wide, similar to GitLab, a breakdown can be helpful in understanding what we're dealing with. Go to this breakdown page for more details.
Additionally, the competitive landscape section of the Continuous Integration category page contains a detailed feature-by-feature breakdown of how we compare to GitHub and Azure DevOps for CI/CD.
リソース
- Azure DevOps
- Azure DevOps announcement blog
- Visual Studio Team Services
- Team Foundation Server
- Azure DevOps public roadmap and release history
- Azure DevOps general positioning deck
コメント/逸話
- Regarding the rename and repackaging of VSTS to Azure DevOps:
Microsoft customers wanted the company to break up the Visual Studio Team Services (VSTS) platform so they could choose individual services, said Jamie Cool, Microsoft's program manager for Azure DevOps. By doing so, the company also hopes to attract a wider audience that includes Mac and Linux developers, as well as open source developers in general, who avoid Visual Studio, Microsoft's flagship development tool set.
- Lots of emphasis on cross platform (windows, Mac, Linux), and free macOS CI/CD is pretty rare.
- All paid plans include unlimited stakeholder users who can view and contribute to work items and boards, and view dashboards, charts, and pipelines
- From https://azure.microsoft.com/en-us/blog/introducing-azure-devops/
Azure DevOps represents the evolution of Visual Studio Team Services (VSTS). VSTS users will be upgraded into Azure DevOps projects automatically. For existing users, there is no loss of functionally, simply more choice and control. The end to end traceability and integration that has been the hallmark of VSTS is all there. Azure DevOps services work great together.
As part of this change, the services have an updated user experience.
Users of the on-premises Team Foundation Server (TFS) will continue to receive updates based on features live in Azure DevOps. Starting with next version of TFS, the product will be called Azure DevOps Server and will continue to be enhanced through our normal cadence of updates.
- HackerNews comments saying it's just a rebrand - PM for AzureDevOps responding:
PM for Azure DevOps here (formerly VSTS). It is a rebranding, but it's more than merely a rebranding. We're breaking out the individual services so that they're easier to adopt. For example, if you're just interested in pipelines, you can adopt only pipelines.
- From a call with a prospect Bank:
- Went with Azure DevOps because
It's platform agnostic, it's in the cloud, great capabilityality, tons of functionality, it does what we need it to do. We like it a lot. It really has nothing to do with Microsoft. Microsoft is very agnostic and open source embracing now, so that the old Java vs .Net thing is kind of over.
- Appealed to a shop that was "more Java than Microsoft technologies". But they had lots of the Microsoft development suite already, and trusted where Microsoft is going.
- Azure DevOps is dropping new releases every sprint (2-3 weeks). Their roadmap is public: Azure DevOps public Roadmap and Release History
- Went with Azure DevOps because
- What does the migration path look like from Azure DevOps to GitLab for SCM and CI/CD??
- SCM migration - Available tools to migrate without losing repo history. Like with any product, centrally managed -> Git takes training.
- CI/CD migration - A little tougher. Most existing will be using build pipelines and release pipelines created through UI. Conversion is task by task reconstruction of pipelines, and potential combining into one on GitLab. Azure DevOps pipeline as code is new, although Microsoft is starting to push it as the default now.
- A developers experience and opinions using Microsoft Devops CI
- Hacker News: Microsoft’s Azure DevOps: An Unsatisfying Adventure
料金
Azure DevOps
- Azure DevOps Services Pricing
- Azure Pipelines Only Pricing
- Azure DevOps On-prem = See TFS Pricing
- Current VSTS and MSDN subscribers get different levels of Azure DevOps. Details can be found at Azure DevOps for Visual Studio subscribers
VSTS
Visual Studio ‘Professional Version’ is the most comparable to GitLab since Visual Studio ‘Enterprise Version’ includes extras outside the scope of DevOps (such as MS Office, etc).
Visual Studio Professional can be purchased under a ‘standard’ or ‘cloud’ model.
- Standard = $1,200 year one (retail pricing), then $800 annual renewals (retail pricing)
- Cloud - $540 per year
Under their ‘modern purchasing model’, the monthly cost for Visual Studio Professional (which includes TFS and CAL license) is $45 / mo ($540 / yr). However, extensions to TFS such as Test Manager ($52/mo), Package Management ($15/mo), and Private Pipelines ($15/mo) require an additional purchase.
TFS
A TFS license can be purchased as standalone product, but a TFS license (and CAL license) is also included when you buy a Visual Studio license / subscription.
MS pushes Visual Studio subscriptions and refers customers who are only interested in a standalone TFS with a ‘classic purchasing’ model to license from a reseller.
Excluding CapEx and Windows operating system license, a standalone TFS license through a reseller in classic purchasing model is approximately $225 per year per instance. The approximate Client Access License is approximately $320 per year.