Как сделать обзор кода с TFS 2015 в Powerbuilder 12.6?
Я анализирую TFS для проверки кода для проекта, созданного в Powerbuilder. Ниже описано, как все устроено:
Мы подключаемся к TFS-репозиторию из Powerbuilder с помощью плагина MSSCCI. К вашему сведению, Powerbuilder связывает объекты и сохраняет их в файле pbl (библиотека powerbuilder). Все вроде зашифровано в пбл. Возможно, TFS не может распознать pbl, поэтому такие объекты, как windows, datawindows, структура помещаются в репозиторий TFS-сервера.
Скажем, у нас есть имя библиотеки project.pbl, в котором есть window1, window2 и т. Д. Теперь в TFS у нас есть папка, аналогичная имени библиотеки - project, и в этой папке у нас есть объекты window1 и window2. Когда мы получаем исходный код из TFS, мы копируем папку в нашу локальную папку вместе с объектами.
Теперь мой вопрос:
1. Когда мы вносим изменения в любой объект в Powerbuilder и регистрируем, как TFS узнает об этих изменениях, так как не имеет информации о библиотеке?
2. Если я извлекаю объект и вносю изменения, изменения не видны в объекте в TFS. Он будет виден только после регистрации кода. В таком случае, как я могу отправить код для проверки кода до регистрации?
Есть ли другой подход, который я могу использовать для проверки кода?
Спасибо Ашиш
2 ответа
С TFS, если вы используете репозиторий Git вместо TFVC и если вы обновляетесь до PowerBuilder 2017 R3, тогда PowerBuilder сохранит недвоичную (текстовую) версию ваших объектов (например, SRD, SRW и т. Д.).
1) через файл PBG. Из быстрого поиска Google:
Когда вы добавляете цель или объект (в цели, которая не находится под контролем источника) в систему контроля версий, PowerBuilder создает файл PBG. Файл PBG отображает объекты в цели в определенный PBL в цели PowerScript или.NET. Для каждого типа PBL создается один файл PBG, поэтому для этих типов целей может быть несколько файлов PBG.
2) Не уверен, что такое "отправить код для проверки кода", но если вы используете TFS для отслеживания дефектов / работы через рабочие элементы, вы можете связать любые измененные объекты с рабочим элементом во время регистрации. По моему опыту, вы должны иметь (по крайней мере,) отдел развития и производственный филиал. Все изменения вносятся в ветку Разработка. Если при проверке или тестировании кода обнаруживается проблема с кодом, он возвращается к разработчику. Если все в порядке, изменения затем объединяются в производственную ветвь.