Заметки консультанта

Шамрай Александр Владимирович

Archive for the ‘devops’ Category

Автоматическое обновление целевой даты исправления ошибки на основе Azure DevOps CLI

Posted by Shamrai Alexander на 12 ноября, 2019

Часто в проектах возникает потребность устанавливать определенные сроки для исправления ошибок определенного приоритета. Т.к. в процессах Azure DevOps отсутствует возможность использовать вычисляемые поля, то решать данную задачу приходится с помощью не-коробочных возможностей (например, Excel или отдельно разработать утилиту на основе Rest API). Однако использование Azure DevOps CLI позволяет значительно сэкономить время, необходимое на решение подобного вопроса.

Попробуем реализовать схожую задачу. Для этого нам понадобится следующее:

  1. PowerShell
  2. Azure DevOps CLI
  3. Personal Access Token
  4. Адрес организации Azure DevOps и наименование проекта
  5. Подготовленный запрос на основе WIQL, которые отберет необходимые рабочие элементы и поля, на основе которых будет выполнять вычисление. Например, можно сразу отбирать дату создания и на ее основе устанавливать целевую дату.

Далее необходимо создать скрипт, который будет включать следующие шаги реализации:

  • Установить значения по умолчанию для адреса организации Azure DevOps и наименования проекта. Это позволит не использовать эти параметры в каждой следующей команде:

az devops configure -d organization=$azdOrg project=$azdProject

  • Выполнить подготовленный ранее запрос. Команда вернет ответ в json формате, поэтому результат нужно конвертировать:

$workItems = (az boards query —wiql «$queryWiql« | ConvertFrom-Json)

  • Обновить необходимое поле для обнаруженный рабочих элементов:

az boards work-item update —id $workItem.id —fields «Microsoft.VSTS.Scheduling.DueDate=$targetDateStr» —discussion «Updated by CLI»

Вот и все. Полный пример можно посмотреть здесь: https://github.com/ashamrai/AzureDevOpsExtensions/blob/master/CustomPSTasks/UpdateBugTargetDate.ps1

Posted in azure, devops, Microsoft | Отмечено: , , | Leave a Comment »

Azure DevOps Rest Api. 20. Просмотр определений сборки для командного проекта

Posted by Shamrai Alexander на 10 июля, 2019

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

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

  • Id – идентификатор определения сборки
  • Name – наименование определения сборки
  • Path – путь, по которому храниться определение сборки
  • Revision– версия определения сборки
  • Queue – очередь, в которую поставлена сборка
  • QueueStatus – состояние сборки в очереди

Пример получения списка определений сборки:

List<BuildDefinitionReference> buildDefs = BuildClient.GetDefinitionsAsync(TeamProjectName).Result;

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

  • Id – идентификатор сборки
  • BuildNumber – номер сборки
  • Status – состояние сборки
  • StartTime – время старта процесса сборки
  • FinishTime – время завершения процесса сборки

Пример получения списка сборок для конкретного определения сборки:

List<Build> builds = BuildClient.GetBuildsAsync(TeamProjectName, new List<int> { buildDef.Id }).Result;

Дополнительно для каждой сборки можно получить список комитов, которые были основой для ее создания, через метод GetBuildChangesAsync:

var changes = BuildClient. GetBuildChangesAsync(TeamProjectName, builds[i].Id).Result;

Пример тестового приложения можно посмотреть здесь:

https://github.com/ashamrai/TFRestApi/tree/master/20.TFRestApiAppExploreBuildDefinitions

Posted in azure, devops, Microsoft, Team Foundation Server, Visual Studio, visual studio team services | Отмечено: , | Leave a Comment »

Azure DevOps Rest Api. 14. Создание и добавление тестовых сценариев

Posted by Shamrai Alexander на 11 мая, 2019

<< Перейти в радел «Azure DevOps Services (TFS/VSTS) Rest Api»

Примечание: На основе Microsoft.TeamFoundationServer.Client 16.150.0-preview

Создание тестового сценария

Примечание: На момент написания статьи не существовало официальных задокументированных возможностей для создания тестовых сценариев через Rest Api. Ниже описанное о тестовых шагах получено опытным путем.

Клиент TestPlanHttpClient не содержит каких-либо методов для создания тестовых сценариев. Тестовые сценарии создаются как обычные рабочие элементы через клиент WorkItemTrackingHttpClient (см. Создание и редактирование рабочих элементов). Особенностью является формирование шагов тестирования и параметров для них.

Структура содержимого шагов тестирования в сценарии

Шаги тестирования содержатся в поле Microsoft.VSTS.TCM.Steps в следующем формате:

<steps id=»0″ last=»{LAST_STEP_ID}»>

<step type=»ActionStep» id=»{STEP_ID}»>

<parameterizedString isformatted=»true»>{ACTION_DESCRIPTION}</parameterizedString>

<parameterizedString isformatted=»true»></parameterizedString>

</step>

<step type=»ValidateStep» id=»{STEP_ID}»>

<parameterizedString isformatted=»true»>{ ACTION _DESCRIPTION}</parameterizedString>

<parameterizedString isformatted=»true»>{VALIDATION_DESCRIPTION}</parameterizedString>

</step>

</steps>

Тут можно выделить следующие атрибуты:

  1. {LAST_STEP_ID} – идентификатор последнего шага.
  2. type – тип шага. Если установлено значение ActionStep, то заполняется только содержимое для первой строки шага(parameterizedString), содержимое второй строки остается пустым. Если же установлено ValidateStep, то обе строки заполняются.
  3. {STEP_ID} – порядковый номер шага. Отсчет начинается с 2.
  4. {ACTION_DESCRIPTION} – описание действий в шаге.
  5. {VALIDATION_DESCRIPTION} – описание проверок правильного выполнения шага.

Структура содержимого параметров шагов тестирования

Если тестовый сценарий не использует локальные параметры, то этот пункт можно упустить. Описание параметров разделяется на две части:

  1. Описание набора параметров.
  2. Описание значений параметров.

Описание набора параметров

Набор параметров содержится в поле Microsoft.VSTS.TCM.Parameters в следующем виде:

<parameters>

<param name=»param1″ bind=»default»/>

<param name=»param2″ bind=»default»/>

</parameters>

Т.е. для каждого параметра в блоке parameters описывается строка <param name=»ИМЯ_ПАРАМЕТРА» bind=»default»/>.

Описание значений параметров

Набор параметров содержится в поле Microsoft.VSTS.TCM.LocalDataSource в следующем виде:

<NewDataSet>

<xs:schema id=’NewDataSet’ xmlns:xs=’http://www.w3.org/2001/XMLSchema&#8217; xmlns:msdata=’urn:schemas-microsoft-com:xml-msdata’>

    <xs:element name=’NewDataSet’ msdata:IsDataSet=’true’ msdata:Locale=»>

        <xs:complexType>

<xs:choice minOccurs=’0′ maxOccurs = ‘unbounded’>

            <xs:element name=’Table1′>

<xs:complexType>

                <xs:sequence>

                    <xs:element name=’param1′ type=’xs:string’ minOccurs=’0′ />

                    <xs:element name=’param2′ type=’xs:string’ minOccurs=’0′ />

                </xs:sequence>

            </xs:complexType>

        </xs:element>

    </xs:choice>

</xs:complexType>

</xs:element>

</xs:schema>

<Table1><param1>value1</ param1>< param2>value2</ param2></Table1>

<Table1>< param1>value3</ param1>< param2>value4</ param2></Table1>

</NewDataSet>

Т.е. это описание набора данных с его содержимым. Для каждого нового параметра необходимо в разделе <xs:sequence> добавить новую строку с описанием параметра: <xs:element name=’ИМЯ_ПАРАМЕТРА’ type=’xs:string’ minOccurs=’0′ /> .

Далее внизу в таблице <Table1> прописываются значения для каждого из параметров. Сколько новых строк будет в таблице – столько итераций тестирования будет запускать мастер выполнения тестовых сценариев.

Пример генерирования содержимого тестовых шагов и параметров находится в файле в TestStepsHelper.cs тестового решения ниже.

Создание сценарий тестирования с его применением может выглядеть следующим образом:

Dictionary<string, object> fields = new Dictionary<string, object>();
LocalStepsDefinition stepsDefinition = new LocalStepsDefinition();
stepsDefinition.AddStep(«Run Application»);

stepsDefinition.AddStep(«Enter creds @user_name @user_password»);

stepsDefinition.AddStep(«Check available functions», «Functions for: @user_role»);

LocalTestParams testParams = new LocalTestParams();

testParams.AddParam(«user_name», new string[] { «admin», «user», «manager» });

testParams.AddParam(«user_password», new string[] { «admin_pswrd», «user_pswrd», «manager_pswrd» });

testParams.AddParam(«user_role», new string[] { «Administrator», «Local User», «Shop Manager» });

fields.Add(«Title», «new test case»);

fields.Add(FieldSteps, stepsDefinition.StepsDefinitionStr);

fields.Add(FieldParameters, testParams.ParamDefinitionStr);

fields.Add(FieldDataSource, testParams.ParamDataSetStr);

CreateWorkItem(TeamProjectName, «Test Case», fields);

А выполнение шагов будет отображаться так:

Рисунок 1. Выполнение теста

Добавление тестового сценария в существующий набор тестов

Тестовые сценарии могут быть добавлены только в статический набор тестов или набор тестов для требования. Для добавления используется метод AddTestCasesToSuiteAsync клиента TestPlanHttpClient с параметрами: список экземпляров класса SuiteTestCaseCreateUpdateParameters, который описывает ссылку на рабочий элемент теста; наименование командного проекта; идентификатор плана тестирования для новых тестовых сценариев и идентификатор набора тестов. Класс SuiteTestCaseCreateUpdateParameters содержит два атрибута (workItem и PointAssignments), мы будем использовать только атрибут workItem для создания ссылки на рабочий элемент. Пример:

TestSuite testSuite = TestPlanClient.GetTestSuiteByIdAsync(TeamProjectName, TestPlanId, testSuiteId).Result;
if (testSuite.SuiteType == TestSuiteType.StaticTestSuite || testSuite.SuiteType == TestSuiteType.DynamicTestSuite)
{

List<SuiteTestCaseCreateUpdateParameters> suiteTestCaseCreateUpdate = new List<SuiteTestCaseCreateUpdateParameters>();


foreach (int testCaseId in TestCasesIds)

suiteTestCaseCreateUpdate.Add(new SuiteTestCaseCreateUpdateParameters()

{

workItem = new Microsoft.VisualStudio.Services.TestManagement.TestPlanning.WebApi.WorkItem()

{

Id = testCaseId

}

});

TestPlanClient.AddTestCasesToSuiteAsync(suiteTestCaseCreateUpdate, TeamProjectName, TestPlanId, testSuiteId).Wait();

}

else

Console.WriteLine(«The Test Suite ‘» + StaticSuitePath + «‘ is not static or requirement»);

Пример тестового приложения можно посмотреть здесь:

https://github.com/ashamrai/TFRestApi/tree/master/14.TFRestApiAppCreateAndAddTestCase

Posted in azure, devops, Microsoft, Team Foundation Server, Visual Studio, visual studio team services | Отмечено: , | Leave a Comment »

 
%d такие блоггеры, как: