Source control explorer где

Обновлено: 04.07.2024

Пытаясь использовать TFS 2010, я смутился с тем, какой вариант использовать при работе с локальными копиями файлов в Visual Studio 2010: Исследователь решений или Исследователь контроля версий .

Исследователь решений - более естественный способ сделать это (по крайней мере, для начинающих, подобных мне), но использование Source control explorer кажется более удобным и продуктивным. Доступно больше опций, но при нажатии на файл вы все равно открываете его локальную копию.

What are advantages of using one approach over the other?
Should I still go File => Open => Project/Solution or should I better use Team Explorer => Source Control (it seems even faster)?
What are situations when using Solution explorer is obviously better (or even the only) option?

Solution explorer is for working with solution, that is for development. When you are opening file from Solution explorer, you are opening a part of your project - VS takes into account what assemblies, namespaces etc. should be visible from this file, which gives you intellisense. Furthermore, context menus on Solution explorer are targeted at development process - notice all these "Build", "Rebuild", "Set as start up project" and so on.

Когда вы просматриваете свое решение в Solution explorer , вы видите только те части, которые используются в исходном коде, я имею в виду скомпилированные файлы, ресурсы и т. Д. Кроме того, может возникнуть ситуация, когда у вас будет файл, включенный в решение, но не включено в исходное управление, и единственное место, где можно увидеть, что оно находится в Исследователь решений .

Source control explorer on the other hand is for working with source control. It allows you adding and removing files in repository, checking in and checking out, updates etc. It has nothing to do with the development process directly - for example Source control explorer won't give you an opportunity to compile anything. Opening file in Source control explorer opens it as a single file - yes, it is still editable, but it does not now about the context, does not give you intellisense and so on.

Когда вы просматриваете свои источники в Исследователь контроля версий , вы не ограничены отдельным решением. Представьте себе ситуацию, когда у вас также есть папка с проектными документами (спецификации, макеты) в исходном элементе управления. Возможно, вы не можете включить их в свое решение, но вам все равно нужно каким-то образом их контролировать - обновите свои версии в исходном управлении, добавьте новые и так далее. Это невозможно, если вы находитесь в Исследователь решений , так как вы не видите ничего, кроме самого решения. Поэтому единственным местом, где вы можете работать с этими файлами, является Исследователь контроля версий .

Подводя итог, Solution explorer предназначен для работы с исходным кодом, то есть для разработки, Исследователь контроля версий предназначен для работы с репозиторием.

Для создания кода командного проекта теперь мы можем открыть его в Visual Studio . Для этого переходим в окно нашего командного проекта saf_team_project ( рис. 11.6) и нажимаем Open in Visual Studio (в правой части окна, около значка VS 2013). Сайт запрашивает разрешение на запуск программы, и после его получения запускается VS 2013, в которой открывается окно Team Explorer и настраивается на проект saf_team_project ( рис. 11.11).

Рис. 11.11. Запуск VS 2013 из Visual Studio Online и открытие в ней командного проекта

Теперь над командным проектом можно выполнить следующие действия, которым соответствуют вкладки:

My Work - планирование заданий (вкладка Team Explorer / My Work изображена на рис. 11.12).

In Progress Work - выполняемые работы над проектом;
Suspended Work - отложенные работы над проектом;
Available Work Items - список всех доступных работ над проектом;
Code Reviews - инспекция кода (она играет весьма важную роль в современных программных проектах).

Pending Changes - изменения, вносимые в код с помощью системы управления исходным кодом при выполнении команды check-in - закрытие исходного файла для редактирования, добавление комментария к новой версии кода, включаемые и не включаемые изменения. Вкладка Team Explorer / Pending Changes изображена на рис. 11.13.

Рис. 11.13. Вкладка Team Explorer / Pending Changes

Source Control Explorer - просмотр рабочего пространства проекта, находящегося под контролем системы управления исходным кодом. Результат выбора этой вкладки показан на рис. 11.14 - вызов Source Control Explorer.

увеличить изображение
Рис. 11.14. Вызов Source Control Explorer выбором одноименной вкладки

Builds - управление сборкой проектов: создание нового определения сборки ( build definition) и просмотр всех определений сборок. Данная вкладка показана на рис. 11.15.

Work Items - список всех выполняемых работ над проектом;

Settings - установки и настройки командного проекта и коллекции командных проектов.

11.5. Резюме

Visual Studio Online - облачный инструмент, аналогичный по функциональности Team Foundation Server , но, как всякий облачный продукт, не требующий инсталляции на клиентском компьютере. Он позволяет создавать командные проекты и управлять ими - включать в проект новых членов, организовывать обсуждение проекта в Team Rooms, контролировать проект с помощью спринтов - назначенных заранее временных сроков и соответствующих им этапов ( работ ), которые должны быть выполнены к этому сроку, помещать проект под контроль системы управления исходным кодом, настраивать и выполнять сборку ( build ) проекта, тестировать проект.

Ключевые термины

Краткие итоги

Git и TFS: история дружбы

Git — распределенная система контроля версий, где каждый разработчик имеет копию всего репозитория, что означает отличную поддержку оффлайн-разработки. Еще у Git есть хорошая, понятная модель бранчинга, и разработчику не надо долго думать о том, как создавать локальные или приватные бранчи для удобства работы. В общем, с Git все хорошо, и на MSDN есть посвященный Git бранч.

Проект Git в Team Foundation Service

После регистрации в TFS на странице команд есть новая кнопка — New Team Project + Git. Пара кликов — и проект Git готов.

Собственно, на этом все. :) Но это — верхушка айсберга, внутри интеграция гораздо сложнее. Дальше — про то, как из Visual Studio подключиться и поманипулировать нашим Git-проектом.

Visual Studio и Git

Делаю сразу оговорку — Visual Studio — не замена существующему UI Git. Visual Studio может быть заменой, но чаще используется в совокупности с другими средствами. Если Git был создан внутри TFS, то у разработчика появляются некоторые фичи, пришедшие из TFS, например, Work Items, но VS спокойно работает с любыми локальными репозиториями и заслуженными Git-деятелями в лице GitHub и BitBucket.

Для подключения к Git-репозиторию достаточно нажать TEAM | Connect to Team Foundation Server.

Откроется Team Explorer. Как видите, у меня уже есть склонированный (с GitHub) репозиторий, и тут же — репозиторий TFS. Для клонирования нового репозитория Git можно нажать Clone и ввести данные подключения.

Для подключения аккаунта Visual Studio Online нажмем Select Team Projects, выберем аккаунт и установим, какой репозиторий надо подтянуть к нам в VS.

После подключения проектов выберем нужный и нажмем в контекстном меню кнопку Clone.

На этом процесс клонирования закончен — в бранче Local Git Repositories в Team Explorer появится склонированный репозиторий. Повторюсь — с помощью Clone можно клонировать любой Git-репозиторий.

Еще одна интересная фича интеграции Visual Studio и Git — это возможность создать новый проект и сразу добавить его в локальную систему контроля версий. Для этого при создании нового проекта в VS достаточно отметить Add to source control.

Перед тем, когда вы будете коммитить что-то в репозиторий, нужно установить данные для коммитов — нажать на Changes и предупреждение о том, что нужно ввести данные.

Полезные функции на этой странице есть еще внутри Repository Settings — можно настроить .gitIgnore и .gitattributes.
Дальше можно коммитить.

Чтобы сделать Pull и получить последние апдейты от команды, нужно перейти на Commits и нажать Fetch для того, чтобы сначала посмотреть, что там вообще придет (и есть ли чему придти).

Все хорошо — нажмем Pull и получим последний апдейт. Дополнительные сведения можно найти тут — Pull changes from the team.

Использование бранчей

Для использования бранчей в Team Explorer выделена специальная секци Branches.

После подключения к репозиторию доступна только master.

Создадим новый бранч, нажав New Branch.

Поскольку бранчи Git локальны до момента Push, новый бранч будет размещен в Unpublished Branches. Поменять бранч для коммитов можно на уже упоминавшейся выше странице Commits.

Замерджить контент можно, нажав Merge и выбрав бранчи. Подробнее про бранчи и мерджи — Git Branching.

Если в процессе мерджа или пулла возникнут конфликты, они тут же могут быть разрезолвены (самые простые, конечно).

Для просмотра истории достаточно нажать View History в контекстном меню бранча.

По нажатию на коммит получим подробные сведения о том, что произошло.

Многое из этого также доступно на портале TFS. Для того, чтобы перейти туда из VS, нужно на странице проекта в Team Explorer нажать Web Portal.

Система контроля версий очень важный компонент, который необходим при разработке программного обеспечения. Контроль версий позволяет разделять разработку на несколько ветвей. Позволяет сравнивать любые версии объектов между собой, чтобы увидеть какие были внесены изменения. При необходимости можно всегда откатиться с поздней версии на более раннюю. Для командной разработки, контроль версий вещь необходимая.

В первых версиях Axapta не имела собственной системы контроля версий. Но однажды, в далеком 2003 году, один разработчик написал первый небольшой интерфейс для работы Aх с системой контроля версий Microsoft SourceSafe. Странно, что хоть Ax уже был куплен Microsoft на тот момент, системы контроля версий не было, хотя в Visual Studio такая уже имелась.

DAX 2009

Первая система контроля версий «из коробки» появилась в Dynamics Ax 2009. Называется она MorphX VCS. Сразу стоит упомянуть, что также был включена поддержка Visual SourceSafe и Team Foundation Server. Но для их разворачивания требуется наличие отдельно настроенной системы контроля версий, к который мы будем подключаться. А чтобы развернуть MorphX VCS необходимо произвести всего несколько настроек прямо из Ax.

Во-первых, необходимо активировать систему контроля версий. Для этого необходимо пройти по пути: «Сервис – Средства разработки – Контроль версий – Настройки» и выбрать пункт «Параметры».

Данная форма позволяет включить систему контроля версий и выбрать какая система будет использоваться. Установить дополнительные параметры, если необходимо и закрыть форму.

Далее по тому же пути необходимо настроить уже «Параметры системы» контроля.

На вкладке «Разное» следует указать или изменить необходимые параметры. В случае наличия ошибок в объекте выявленных в процессе компиляции, такой объект не будет помещен в хранилище контроля версий.

Параметр «Строка состояния» будет отображать описание системы.

На вкладке «Правила объектов» можно указать типы и имена объектов, которые не могут быть добавлены с систему управления версиями.

На следующим шаге, необходимо создать репозитарий для системы контроля. Для этого требуется протий по пути: «Сервис – Средства разработки – Контроль версий – Настройки» и выбрать пункт «Создать репозитарий».

После завершения создания репозитария, в базе данных Ax в таблице SysVersionControlMorphXIte2541 можно увидеть объекты, добавленные в контроль версий. В АОТ таблица имеет имя SysVersionControlMorphXItemTable.

Версии объектов хранятся в таблице SysVersionControlMorphXRevisionTable.

Извлеченные объекты можно увидеть в таблице SysVersionControlMorphXLockTable.

У объекта добавленного в систему контроля версий можно, например, через контекстное меню посмотреть историю или сравнить версии объекта.

Добавлять новые объекты в контроль версий необходимо самостоятельно, через контекстное меню объекта.

Важно помнить, так как таблицы системы контроля версий находятся в базе данных Ax, то при восстановлении базы данных, например, с Prod, данные об изменениях объектов будут утеряны.

Альтернативой встроенной системе контроля версий служит система Team Foundation Server, широко распространенная в данный момент. Для ее настройки существует документ Microsoft Dynamics AX 2009 White Paper: Team Foundation Server Version Control Setup.

DAX 2012

В Dynamics AX 2012 продолжает существовать собственная система MorphX VCS и также обеспечивается поддержка внешних систем контроля.

В 2012 году известные разработчик и программный архитектор Martin Drab написал статью, в которой поднял тему общей и изолированной среды разработки.

В статье он говорит, про то, что Ax 2012 стал более сложной системой, в которой трудно производить совместную разработку в одной общей среде, особенно если команда большая. Что Microsoft сама никак не решает проблему совместной разработки, также и командные проекты не хотят тратить силы и время на поиск решения.

Дополнительную проблему привнес CIL, отладка которого блокирует весь AOS, что создает неудобства при совместной разработке и требует наличия отдельного AOS, для решения данной проблемы. Наличие отдельных сред, само по себе исключает данную проблему.

Его статья вызывала разногласия. В основном они касались накладных расходов, связанных с разворачиванием отдельных сред. В одном из комментариев был произведен расчет, что при существующем количестве клиентов и размере их баз, на одну изолированную среду разработки, только для базы данных будет требоваться 1Tb дискового пространства. В другом был расчет, по которому на 10 разработчиков, при 20 клиентах требуется разворачивать 200 сред разработки.

Что такое изолированная среда? Изолированная среда разработки означает, что у каждого разработчика есть свой собственный изолированный код для работы. Это также требует отдельной базы данных (разные приложения могут иметь разную схему базы данных) и предпочтительно изолированной операционной системы и всех других необходимых компонентов.

Поэтому он предложил выход, который основан на использовании системы контроля версий, а именно TFS.

Отдельные рабочие пространства

В параметрах системы управления версиями указываем единственный путь до репозитария. Включать систему контроля пока не нужно.

Далее в импортированном проекте необходимо найти и запустить пункт меню «AddaxPlugin». В форме сначала нажать на кнопку «Update plugins». После этого в списке плагинов активировать «User repository» и нажать кнопку «Configure».

Далее необходимо сконфигурировать рабочие пространства пользователей. Для этого необходимо добавить строки и выбрать необходимых пользователей.

Путь до репозитария пользователя создается автоматически, путем добавления Id пользователя к пути, указанном в параметрах системы управления версиями. Символическая ссылка создается при сохранении записи и удаляется, при удалении записи пользователя.

Вот символические ссылки для пользователей administrator и hal и общая папка Shared, на которую указывают все ссылки (и которая также создается автоматически).

Данных подход можно использовать и для Ax 2009.

D365

Первым шагом является настройка Visual Studio Online (VSO). Visual Studio Online теперь поддерживает контроль версий Git, но если решение будет развернуто на стороне заказчика, Microsoft рекомендует выбрать Team Foundation Version Control. По крайней мере, для любых проектов, которые взаимодействуют с Life Cycle Services (LCS).

Создание проекта в Visual Studio

Теперь создадим проект. Назовем его Ax7Experimentation.

Далее необходимо подключить «Visual Studio» к проекту и продолжать оттуда.

Запускаем «Visual Studio» под администратором, идем в меню «Team» и выбираем «Manage Connections». Откроется «Team Explorer».

Указываем адрес, состоящий из имени учетной записи, которую мы указывали при регистрации и доменного имени. Выбираем созданный проект и нажимаем «Connect».

Далее необходимо настроить сопоставление рабочего пространства с локальной директорией. Локальная директория служит промежуточным хранилищем для файлов, которые не были отправлены в систему контроля.

Для этого нажимаем на «Configure your workspaces», после чего необходимо указать путь к директории, где будет хранится код. Для работы D365 эта папка будет содержать только проекты и сам код. Все артефакты метаданных Dynamics будут находиться в другой папке.

Создадим папку AxTFS и выберем ее.

Теперь есть локальная папка, сопоставленная с VSTO. Нажмем кнопку «Source Control Explorer», чтобы открыть проводник. Здесь закончим сопоставления рабочей области и создадим начальные необходимые папки. Создадим папки Trunk и Main. В Main будут храниться файлы, относящиеся к проектам Visual Studio, в ней создадим папку Projects.

Последнее, необходимо указать VSTS, где хранить файлы метаданных D365. Эти файлы находятся в папке, контролируемой службой AOS: «C:\AOSService».

Для этого в директории «Main» создадим еще одну поддиректорию «Metadata». Теперь ее необходимо сопоставить с локальной директорией «AOSService\PackagesLocalDirectory». Для этого идем в «Workspace» и добавляем новую строку, в которой указываем директорию «Metadata» и локальную директорию метаданных.

Далее возвращаем ожидающие файлы в хранилище системы контроля и конвертируем директорию «Main» в ветвь. Для этого вызываем ее контекстное меню, идем в подменю «Branching and Merging» и выбираем «Convert to Branch».

Новый проект D365 должен хранится в директории «Projects», управляемой VSTS. Созданное сопоставление метаданных папок позволит «Visual Studio» создавать элементы проекта в правильном месте и при этом добавлять их в систему управления версиями.

Читайте также: