| Новые программы oszone.net |  |
Team Foundation Service, финальная версия которого была выпущена в октябре 2012 г., представляет собой облачную версию Visual Studio Team Foundation Server (TFS) и предлагает ряд функций, которые помогут вам поставлять качественное программное обеспечение. И очевидно, что программы, о разработке которых вы еще только думаете, почти наверняка будут ориентированы на Windows 8. Вероятно, вас интересует, можно ли смешивать возможности двух продуктов: использовать Team Foundation Service для сборки приложений Windows Store. К сожалению, в готовом виде это невозможно из-за некоторых ограничений, о которых я расскажу потом в статье. Однако я также покажу, что сделать, чтобы обойти эту проблему, и как проверять приложения Windows Store перед процессом сборки. Начнем с краткого обзора Team Foundation Service. Обзор Team Foundation ServiceКак облачный сервис Team Foundation Service позволяет разработчикам получать доступ к средствам TFS без возни с его установкой и управлением. Просто подпишитесь (бесплатно!) по ссылке bit.ly/ZusqUY и можете пользоваться сервисом. Среди сервисов, предлагаемых этим продуктом, имеет смысл выделить три основных функции для разработки и поставки высококачественного программного обеспечения. Управление исходным кодом Вы можете использовать функцию управления исходным кодом совместно со своим текущим инструментарием и предпочитаемым языком программирования — контроллер исходного кода работает практически с любым типом файлов (C#, C++, HTML, PHP, Java и т. д.). Если вы применяете такую IDE, как Visual Studio или Eclipse, то можете по-прежнему использовать ее для разработки приложений и ставить свои файлы на контроль исходного кода. Архитектура контроллера исходного кода (source controller) предоставляет локальную рабочую область, где хранится локальная копия исходного кода. В отсоединенном режиме все модификации применяются в этой рабочей области. Когда вы вновь подключаетесь, вы просто ставите код на контроль, чтобы передать его на сервер, сохраняя полную историю всех версий; это позволяет отслеживать и откатывать изменения. Совместная работа Team Foundation Service позволяет эффективнее работать в коллективе — главным образом с помощью инструмента, который называется доска задач (task board). Эта доска задач доступна из любого современного браузера, позволяющего создавать собственные информационные панели (dashboards). Доска задач используется для управления информацией о рабочих элементах, состоянии сборки, результатов тестов и т. д., как показано на рис. 1.
Build Service Этот сервис все еще находился в стадии предварительной версии на момент написания данной статьи. Build Service основан на Team Build, который является частью TFS 2010, и обеспечивает автоматизированную сборку в облаке. Build Service может использовать все стандартные средства Team Build, в том числе непрерывную сборку с интеграцией (continuous integration), сборки в ночное время и сборки с постановкой на контроль по совпадению (gated check-in builds). Более того, используемый шаблон сборки является полностью настраиваемым. Есть даже шаблон «ready to go» для выполнения непрерывного развертывания в Windows Azure (вы можете ставить свой код на контроль в системе управления исходным кодом и видеть его обновления на веб-сайтах Windows Azure). Build Service размещен на сервере сборки, развернутом вместе с Windows Server 2008 R2, Team Build, Visual Studio 2010 (или выше) и другим ПО (полный список необходимого ПО и параметров см. внизу страницы по ссылке bit.ly/12Sf99Z). Конфигурация по умолчанию годится для большинства приложений, но только не для Windows Store. Как видно на рис. 2, приложения Windows Store должны компилироваться в Windows 8 (или Windows Server 2012), а это ПО не устанавливается на сервере сборки.
Поэтому, как уже говорилось, сборка приложений Windows Store с помощью Team Foundation Service изначально невозможна. Но, как вы увидите, существует обходной способ. По сути, он заключается в установке для Team Foundation Service компьютера с Windows 8, который станет новым агентом сборки, выделенным специально для приложений Windows Store. Я покажу, как это делается. Сборка приложений Windows Store с помощью Team Foundation ServiceНиже перечислены этапы, необходимые для сборки приложений Windows Store с помощью Team Foundation Service. Установка Build Service Первым делом вам потребуется компьютер под управлением Windows 8. Это может быть физическая или виртуальная машина (VM) — это не имеет значения, пока эта машина доступна через Интернет. Далее установите на ней TFS 2012. Заметьте, что установка TFS не означает, что он будет сконфигурирован должным образом и готов к использованию. Единственная причина его установки в том, что он позволяет конфигурировать Build Service. Вам не понадобится Team Foundation Application Server, так как он уже есть у вас от Team Foundation Service. После установки Build Service можно его сконфигурировать на использование выделенного набора групповых проектов. В этом случае, поскольку вы не будете настраивать другие компоненты TFS и хотите задействовать Team Foundation Service, укажите набор групповых проектов, доступный по вашей учетной записи Team Foundation Service, и завершите конфигурирование, как показано на рис. 3.
Конфигурирование Build Service Для следующего этапа вы должны понимать некоторые основы работы с TFS и его архитектуру процесса сборки. У каждого TFS есть набор выделенных контроллеров сборки (build controllers). Контроллер сборки — это конечная точка, которая принимает запрос на сборку и выполняет его, используя выделенные агенты сборки. Агент сборки берет на себя большую часть важной работы в процессе сборки: он получает файлы из системы управления исходным кодом, компилирует код, выполняет модульные тесты и т. д. Team Foundation Service поставляется с выделенным контроллером сборки (размещенным контроллером сборки [hosted build controller]), поэтому вы можете решить, что вам достаточно лишь создать новый агент для работы с этим контроллером. К сожалению, подключить агент сборки на предприятии к размещенному контроллеру сборки нельзя. Вы должны либо выбрать другой контроллер сборки, либо создать новый контроллер сборки. Чтобы не усложнять картину, давайте создадим новый контроллер, как показано на рис. 4.
Как только контроллер подготовлен и запущен, следующий шаг — создание нового агента, выделенного для сборки приложений Windows Store. Создать новый агент сборки не сложнее, чем щелкнуть ссылку New Agent, а затем заполнить поля. В реальной производственной среде вам может потребоваться больше агентов для вашего контроллера сборки, поэтому убедитесь, что приложения Windows Store будут собираться только агентами, выполняемыми в Windows 8, и для этого добавьте выделенный тег, как показано на рис. 5. Это не обязательно именно сейчас: когда вы позднее будете создавать определение сборки, вы сможете указать этот тег, чтобы гарантировать, что в процессе сборки будет использоваться только этот агент.
Прежде чем перейти к следующей части, нужно открыть свойства Build Service и настроить его на интерактивное выполнение. Этот этап не обязателен, если вы хотите лишь собирать приложения Windows Store. Но, если вы предполагаете проверять свои приложения, вам понадобится установить и запустить на машине сборки Team Foundation Service и Build Service, а это невозможно, когда Build не настроен на интерактивное выполнение. На странице Builds в Visual Studio Team Explorer щелкните Actions, а затем Manage Build Controllers, чтобы открыть окно со списком всех установленных контроллеров сборки (с выделенными им агентами). Если конфигурация правильна, вы должны увидеть новый контроллер и агент. Подготовка агента сборки к выполнению модульных тестов Если компьютер, на котором размещен агент сборки, будет использоваться для выполнения модульных тестов, вам потребуется пройти еще два этапа. Сначала на этот компьютер надо установить лицензию разработчика для Windows 8. Лицензии разработчиков бесплатны, но их нужно возобновлять каждые 30 дней (или 90 дней, если у вас есть учетная запись Windows Store), и вы можете получить их столько, сколько вам нужно, если у вас уже имеется учетная запись Microsoft. Получить лицензию разработчика можно двумя способами. На своем компьютере сборки просто создайте приложение Windows Store, открывающее диалоговое окно, из которого можно получить лицензию. Если вы не хотите создавать приложение-пустышку на машине сборки, тогда выполните следующую команду Windows PowerShell, чтобы открыть то же самое диалоговое окно: C:\PS> Show-WindowsDeveloperLicenseRegistration Получив лицензию разработчика, вы должны сгенерировать и установить на машине с агентом сборки сертификат модульных тестов (из проекта кода, содержащего нужные вам модульные тесты). Для этого этапа сгенерируйте пакет приложения на компьютере разработки. В Visual Studio выберите Store | Create App Package. Это приведет к созданию папки, содержащей приложение Windows Store (в файле с расширением .appx) и его сертификат. Чтобы установить сертификат на машину сборки, откройте окно командной строки от имени администратора и введите команду: certutil -addstore root certificate_file Заметьте, что certificate_file — это путь к файлу сертификата. Создание приложений Windows Store После запуска контроллера и агента создание приложений Windows Store становится идентичным разработке любых других приложений. Вам нужно лишь подготовить определение новой сборки и указать, что вы хотите использовать контроллер новой сборки, которую вы только что подготовили. Чтобы убедиться, что в процессе сборки будет использоваться агент, выполняемый в Windows 8, на вкладке Process определения сборки выберите тег, указанный вами после создания этого агента (рис. 6).
Теперь постановка новой сборки с только что созданным определением в очередь приводит к ее запуску, и благодаря указанному тегу вы можете быть уверены, что сборка выполняется с правильным агентом, поэтому она не закончится неудачей. Как видите, сборка приложения Windows Store с помощью Team Foundation Service довольно проста и очень функциональна, а вы можете полностью настраивать процесс сборки. Но одна проблема все еще имеется. Даже если сборка завершится успешно, это не означает, что приложение будет корректно выполняться или даже что оно пройдет все базовые этапы проверки. Так что далее я поясню, как проверять приложение и как сообщать пользователям (через отчет о сборке), прошла ли проверка. Проверка приложений Windows Store в процессе сборкиКак вы, вероятно, знаете, для публикации в Windows Store приложение должно быть сертифицировано. То есть оно должно пройти обязательные этапы проверки. Проверять приложения можно в процессе сборки. Это легко делается простым добавлением события, генерируемого после сборки (post-build event), в результате которого будет запускаться Windows App Certification Kit (ACK) для проверки приложения. Но изначально процесс проверки не уведомляет пользователей о результатах. Я покажу, как расширить процесс сборки для включения этого этапа. Чтобы интегрировать запуск ACK в процесс сборки, надо просто модифицировать ваш файл проекта, добавив PostPackageEvent: <Target Name="PostPackageEvent" AfterTargets="_GenerateAppxPackage"> <Exec Command=""$(TargetPlatformSdkPath)App Certification Kit\appcert.exe" reset"/> <Exec Command=""$(TargetPlatformSdkPath)\App Certification Kit\appcert.exe" test -apptype windowsstoreapp -AppxPackagePath "$(FinalAppxPackage)" –reportoutputpath "$(outdir)\ValidationResult.xml"" /> <Exec Command="copy "$(userprofile)\appdata\Local\Microsoft\appcertkit\ValidationResult.htm" "$(outdir)\ValidationResult.htm""/> </Target> При выполнении этот код создаст файл ValidationResult.html, который содержит результаты проверки, выполненной ACK. Если вы подключены к серверу сборки во время процесса сборки, то увидите, что приложение запускается для проверки ACK. Это нормально; приложение устанавливается, проверяется, а затем автоматически удаляется по завершении теста. Вспомните, что вы сконфигурировали Build Service на интерактивное выполнение: именно это разрешает установку и выполнение приложения. Если бы вы этого не сделали, при сборке возникла бы ошибка. Сам процесс сборки никак не затрагивается результатами проверки, так что пользователи смогут просто узнавать, были ли какие-нибудь ошибки при проверке приложения. К счастью, вы можете расширить отчет о сборке, чтобы включить в него сообщения о любых возникших ошибках. Давайте посмотрим, как настроить отчет о сборке для интеграции результатов проверки утилитой ACK. Настройка отчета о сборке ACK создает как HTML-файл, так и XML-файл и сохраняет их в выбранной вами папке. XML-файл можно использовать для создания собственной операции рабочего процесса, которая будет модифицировать отчет о сборке для уведомления пользователей о результатах проверки. Код, создающий эту операцию, довольно прост. Он находит XML-файл (содержащий результаты проверки), считывает его для поиска значения атрибута OVERALL_RESULT и возвращает это значение. На рис. 7 показан код, который создает операцию CheckWackResultsActivity. Рис. 7. CheckWackResultsActivity [BuildActivity(HostEnvironmentOption.All)]
public sealed class CheckWackResultsActivity : CodeActivity<bool>
{
[RequiredArgument]
public InArgument<string> DropLocation { get; set; }
[RequiredArgument]
public InArgument<string> WackResultsFilename { get; set; }
[RequiredArgument]
public InArgument<string> WackReportFilename { get; set; }
public OutArgument<string> WackReportFilePath { get; set; }
// Если ваша операция возвращает значение, наследуйте
// от CodeActivity<TResult> и возвращайте значение
// из метода Execute
protected override bool Execute(CodeActivityContext context)
{
string dropLocation = context.GetValue(this.DropLocation);
string wackResultsFilename =
context.GetValue(this.WackResultsFilename);
string wackReportFilename = context.GetValue(this.WackReportFilename);
var dropLocationFiles = Directory.GetFiles(dropLocation, "*.*",
SearchOption.AllDirectories);
if (dropLocationFiles.Any())
{
var resultFile = dropLocationFiles.FirstOrDefault(
f => Path.GetFileName(f).ToLowerInvariant() ==
wackResultsFilename.ToLowerInvariant());
if (!string.IsNullOrWhiteSpace(resultFile))
{
var xDocument = XDocument.Load(resultFile);
var reportElement = xDocument.Element("REPORT");
if (reportElement != null)
{
var resultAttribute = reportElement.Attribute("OVERALL_RESULT");
if (resultAttribute != null)
{
context.SetValue(this.WackReportFilePath,
Path.GetDirectoryName(resultFile));
var validationResult = resultAttribute.Value;
// Провал или прохождение
if (validationResult.ToLowerInvariant() == "fail")
{
return false;
}
return true;
}
}
}
throw new InvalidOperationException(
"Unable to find the Windows App Certification Kit results file!");
}
else
{
throw new InvalidOperationException(
"There are no files in the drop location!");
}
throw new InvalidOperationException(
"Unknown error while checking the content of the Windows App
Certification Kit results file!");
}
}По умолчанию операции в процессе сборки выполняются агентами сборки. Но бывают некоторые сценарии, где вам нужно, чтобы операция выполнялась едва ли не на первом этапе, даже до начала сборки или как последний этап перед самым концом процесса сборки. Такая гибкость требует выполнения операции контроллером, а не агентом. Для этого можно задействовать атрибут BuildActivityAttribute, который принимает в качестве аргумента перечислимое значение HostEnvironmentOption.All (как на рис. 7). Заметьте: если вы используете неправильное значение перечисления HostEnvironmentOption, то получите ошибку в процессе сборки. Класс CheckWackResultsActivity наследует от CodeActivity<bool>, чтобы его значение результата можно было использовать для отображения корректного сообщения в отчете о сборке. Для вывода этого сообщения можно задействовать новую операцию, доступную в TFS 2012: WriteCustomSummaryInfo. Эта операция очень полезна, если вы хотите добавить сообщение в отчет о сборке, так как вместо включения простого текста она позволяет добавлять сообщение в определенную категорию в отчете. Вы должны задать следующие свойства:
Поэтому, используя новую операцию и WriteCustomSummaryInfo, я могу модифицировать процесс сборки для получения результатов проверки и добавления нового раздела в отчет о сборке. На рис. 8 показан XAML-код модифицированного процесса сборки. Для публикации в Windows Store приложение должно быть сертифицировано. Рис. 8. Модифицированный процесс сборки <Sequence DisplayName="Windows 8" sap2010:WorkflowViewState.IdRef="Sequence_4"> <Sequence.Variables> <Variable x:TypeArguments="x:Boolean" Name="WackToolRanSuccessfully" /> <Variable x:TypeArguments="x:String" Name="WackReportFilePath" /> </Sequence.Variables> <c:CheckWackResultsActivity DropLocation="[DropLocation]" sap2010:WorkflowViewState.IdRef="CheckWackResultsActivity_3" Result="[WackToolRanSuccessfully]" WackReportFilePath="[WackReportFilePath]" WackReportFilename="ValidationResult.html" WackResultsFilename="ValidationResult.xml" /> <If Condition="[Not WackToolRanSuccessfully]" sap2010:WorkflowViewState.IdRef="If_4"> <If.Then> <Sequence sap2010:WorkflowViewState.IdRef="Sequence_6"> <mtbwa:WriteCustomSummaryInformation sap2010:WorkflowViewState.IdRef= "WriteCustomSummaryInformation_2" Message="["Windows App Certification Kit ran with errors. Click [here](" & WackReportFilePath & ") to access the folder containing the report."]" SectionDisplayName="Windows 8" SectionKey="Windows8" SectionPriority="75" mva:VisualBasic.Settings= "Assembly references and imported namespaces serialized as XML namespaces" /> <mtbwa:WriteBuildError sap2010:WorkflowViewState.IdRef="WriteBuildError_1" Message="Windows App Certification Kit ran with errors." /> <mtbwa:SetBuildProperties CompilationStatus= "[Microsoft.TeamFoundation.Build.Client.BuildPhaseStatus.Failed]" DisplayName="Set Status and CompilationStatus to Failed" sap2010:WorkflowViewState.IdRef="SetBuildProperties_1" mtbwt:BuildTrackingParticipant.Importance= "Low" PropertiesToSet="CompilationStatus" /> </Sequence> </If.Then> <If.Else> <mtbwa:WriteCustomSummaryInformation sap2010:WorkflowViewState.IdRef="WriteCustomSummaryInformation_1" Message="["Windows App Certification Kit ran with success. Click [here](" & WackReportFilePath & ") to access the folder containing the report."]" SectionDisplayName="Windows 8" SectionKey="Windows8" SectionPriority="75" mva:VisualBasic.Settings= "Assembly references and imported namespaces serialized as XML namespaces" /> </If.Else> </If> </Sequence> Заметьте на рис. 8, что, если проверка завершается неудачей, состояние компиляции выставляется в «Failed», чтобы прекратить дальнейший процесс сборки. Это не обязательно, и вы можете удалить это, если предпочитаете всегда заканчивать процесс сборки независимо от результатов проверки. Теперь всякий раз, когда инициируется сборка, отчет о сборке показывает новый раздел, выделенный Windows 8, где отображаются результаты проверки (рис. 9).
Используя WriteCustomSummaryInfo, отчет о сборке можно расширить только текстом и ссылками. Если требуется более сложная модификация (например, добавление изображения), вы можете по-прежнему применять методики, поддерживаемые TFS 2010. Настройка шаблона процесса сборки для приложений Windows Store открывает массу возможностей, и хорошая новость в том, что такая настройка во многом одинакова как для Team Foundation Service, так и для TFS, размещенного на предприятии.
Теги:
Team Foundation Service.
Комментарии посетителей
Комментарии отключены. С вопросами по статьям обращайтесь в форум.
|
|
.png)
.png)
.png)
.png)
.png)
.png)
.png)
