Ожидаемые результаты выполнения заданий

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

  1. Уметь использовать средства командной работы на платформе GitHub:
    • Создавать Issues, кастомизировать перечень и шаблоны их создания, а также использовать метки для Issues
    • Создавать и использовать канбан-доски, добавлять Issues на канбан-доски
    • Фомировать группу Issues в итерацию с использованием Milestones
    • Создавать Pull Requests и связывать их с Issues
    • Настраивать серверные билды, Continuous Integration и автоматическое развертывание приложений с использованием Travis CI
  2. Уметь использовать средства командной работы Azure DevOps (TFS):
    • Создавать ораганизации и проекты в Azure DevOps
    • Работать с канбан-досками и планировать итерации
    • Работать с Git- и TFVC-репозиториями, привязывать изменения в коде к задачам
    • Создавать серверные билды
    • Атоматизировать релизы приложения на основе результатов выполнения серверных билдов
    • Использовать галереи пакетов на основе Azure Artifacts

Задания по модулю

Задание 1. Использование средств командной работы платформы GitHub

  1. В репозитории, который использовался при выполнении задания первого учебного модуля (с кодом клиентского приложения), создать шаблоны Issues для создания новой задачи и новой ошибки. Текст шаблонов может быть произвольным, но должен соответствовать типу создаваемого Issue. С помощью шаблона для задачи в Issue также должна добавляться метка Feature, а с помощью шаблона для ошибки - метка Bug.
  2. Создать три Issue на основе подготовленных шаблонов - две задачи и одну ошибку. Функционал для задач и ошибки придумать самостоятельно (в качестве ошибки, например, можно описать необходимости исправления цветовой гаммы или стилей списка или других частей страниц приложения).
  3. Всем созданным Issues добавить Milestone, ожидаемый срок выполнения Milestone установить любой в пределах двух недель с момента создания Issues.
  4. Внури репозитория с клиентским приложением создать канбан-доску, на которой все задачи могут находиться в одном из четырех состояний: “Новые”, “Активные”, “В работе”, “Выполнены” (имена соответствующих “карточек” на канбан-доске могут быть как русские, так и английские).
  5. Все созданные Issues добавить на канбан-доску и изначально задать им статус “Новые”.
  6. Создать два дополнительных аккаунта (можно, например, с временных Email-ов) на GitHub для работы от лица других разработчиков над Вашими задачами. Одному из созданных аккаунтов предоставить доступ для возможности внесения изменений в ваш репозиторий с клиентским приложением, другому доступ не предоставлять.
  7. С использованием дополнительных аккаунтов выполнить реализацию одной задачи и ошибки, описанных выше:
    • При реализации использовать подход Git Flow: создать ветку develop, задачу и ошибку выполнить в отдельных ветках, которыя должны быть созданы с ветки develop. Имя ветки для выполнения задачи должно начинаться с префикса “feature-“, имя ветки для исправления ошибки - с префикса “fix-“.
    • Задача должна быть реализована из-под аккаунта, который имеет доступ на запись в репозиторий с клиентским приложением. По завершении выполнения задачи должен быть создан пулл реквест “внутри” репозитория - с ветки для задачи в ветку develop. Пулл реквест должен быть связан с соответствующем Issue для задачи. После создания пулл реквеста статус задачи на канбан-доске должен быть изменен на “Выполнена”.
    • Ошибка должна быть исправлена из-под аккаунта, у которого нет прав на запись в репозиторий с клиентским приложением. Для исправления ошибки должен быть создан форк основного репозитория, по завершении исправления ошибки должен быть сделан пулл реквест в основной репозиторий, с которого был сделан форк. Пулл реквест должен быть связан с соответствующем Issue для задачи. После создания пулл реквеста статус задачи на канбан-доске должен быть изменен на “Выполнена”.
  8. Пулл реквест с решением задачи должен быть принят, соответствующая Issue при принятии пулл реквеста должна быть автоматически закрыта (в Issue должна присутствовать ссылка на пулл реквест или коммит, который ее закрыл).
  9. Пулл реквест с исправлением ошибки должен оставаться открытым, принимать и закрывать его не требуется.
  10. Для репозитория должен быть настроен серверный билд и Continuous Integration с использованием сервиса Travis CI:
    • Серверный билд должен запускаться при каждом коммите в репозиторий
    • В процессе работы серверного билда доллжны запускаться тестовые коллекции, которые были экспортированы из Postman при выполнении задания 2 первого учебного модуля, при помощи инструмента Newman.
    • Билды, которые запущены с веток master и develop, должны инициировать автоматическое развертывание клиентского приложения на GitHub Pages, связанных с данным репозиторием (код клиентского прилжения должен попадать в папку с именем исходной ветки, т.е. “master” или “develop”, внутри ветки gh-pages). Если в вашем приложении используется система сборки (например, Webpack), то в процессе выполнения серверного билда она должна отрабатывать, и на GitHub Pages должно попадать “собранное” клиентское приложение.
  11. В репозитории с клиентским приложением должны присутствовать файлы README.md и CONTRIBUTING.md (можно использовать как английский, так и русский язык при написании содержимого файлов):
    • В файле README.md должно присутствовать описание вашего клиентского приложения, а также ссылки на развернутые версии приложения с веток master и develop на GitHub Pages.
    • В файле CONTRIBUTING.md должно присутствовать описание правил добавления исходного кода в ваш репозиторий (правила могут быть сформулированы в произвольном виде, не обязательно пытаться сформулировать “полноценный” набор правил - файл должен быть создан для примера).

Вспомогательные ресурсы:

  1. Создание шаблонов для Issues и пулл реквестов на GitHub.
  2. Continuous Integration для новичков
  3. Официальный Travis CI Tutorial
  4. Официальные гайды GitHub

Задание 2. Использование Azure DevOps (TFS)

  1. Создать новую организацию в Azure DevOps Services.
  2. В организации Azure DevOps Services создать приватный проект. Для нового проекта:
    • В качестве системы управления версиями выбрать Git
    • В качестве процесса для рабочих элементов выбрать Agile
  3. В созданном проекте добавить TFVC-репозиторий в Azure Repos
  4. Создать один дополнительный аккаунт для Azure DevOps (можно, например, с временных Email-ов) - для работы от лица другого разработчика над Вашими задачами. Нового пользователя добавить в созданную организацию с уровнем доступа Basic.
  5. В баклоге проекта в Azure Boards создать три требования (User Story) со следующими названиями:
    • Создание npm-пакета chance-js
    • Установка пакета chance-js в приложение
    • Настройка CI/CD для приложения
  6. Для требования Создание npm-пакета chance-js добавить задачи со следующими названиями:
    • Добавление исходных файлов в репозиторий. Для задачи добавить произвольное описание. Задачу назначить на пользователя “основного” (Вашего) аккаунта.
    • Создание билда для публикации пакета. Для задачи добавить произвольное описание. Задачу назначить на пользователя “основного” (Вашего) аккаунта.
  7. Для требования Установка пакета chance-js в приложение добавить задачи со следующими названиями:
    • Добавление зависимости от пакета chance-js. Для задачи добавить произвольное описание. Задачу назначить на пользователя “дополнительного” аккаунта.
  8. Для требования Настройка CI/CD для приложения добавить задачи со следующими названиями:
    • Добавление билда приложения. Для задачи добавить произвольное описание. Задачу назначить на пользователя “дополнительного” аккаунта.
    • Публикация приложения на GitHub Pages. Для задачи добавить произвольное описание. Задачу назначить на пользователя “основного” (Вашего) аккаунта.
  9. Запланировать созданные задачи на итерацию. Итерация должна иметь двухнедельный срок с дня начала выполнения данного задания. Название итерации может быть произвольное.
  10. В TFVC-репозиторий проекта в Azure Repos добавить файлы из GitHub-репозитория библиотеки Chance:
    • Склонировать GitHub-репозиторий библиотеки Сhance на локальную машину.
    • В файле package.json изменить имя пакета на chance-js
    • В файле gulpfile.js использование библиотеки gulp-uglify заменить на gulp-butternut для задачи build.
    • Проверить, что команды gulp lint, gulp test и gulp build выполняются локально без ошибок.
    • Добавить файлы из модифицированной версии библиотеки Chance с локальной машины в TFVC-репозиторий (с использованием Visual Studio, либо через веб-интерфейс Azure DevOps Services). Добавление файлов можно произвести одним или несколькими чекинами. Каждый чекин должен быть связан с задачей Добавление исходных файлов в репозиторий требования Создание npm-пакета chance-js. Комментарии к чекинам должны иметь следующий формат: <дата>. <Название задачи>. <Комментарий>.
    • По мере выполнения задачи ее статус должен меняться на доске. Чекины должны быть сделаны пользователем, на которого была назначена задача. Задача после окончания работы над ней должна находиться в статусе Resolved.
  11. В Git-репозиторий проекта в Azure Repos добавить файлы из GitHub-репозитория Issue Tracker Demo (можно предварительно склонировать себе репозиторий на локальную машину).
  12. Создать “ленту” Azure Artifacts:
    • В настройках “ленты” должен быть указан Upstream-источник для доступа к npm-пакетам из репозитория https://registry.npmjs.org/ через данную “ленту” (чтобы в приложении иметь возможность устанавливать не только пакеты из “ленты”, но и из данного публичного репозитория npm-пакетов).
  13. Создать билд, который будет публиковать npm-пакет chance-js из TFVC-репозитория в Azure Repos, в “ленту” Azure Artifacts:
    • Можно использовать любой подходящий пул агентов.
    • В процессе сборки приложения перед публикацией npm-пакета необходимо выполнять gulp-задачи lint, test и build.
    • Continuous Integration для данного билда не должен быть включен, то есть билд должен запускаться вручную.
    • По мере создания билда статус задачи Создание билда для публикации пакета требования Создание npm-пакета chance-js должен меняться на доске. Задача после окончания работы над ней должна находиться в статусе Resolved.
    • С помощью созданного билда опубликовать пакет chance-js в “ленту” Azure Artifacts проекта.
  14. В приложение из Git-репозитория в Azure Repos добавить зависимость от npm-пакета chance-js, который опубликован в “ленте” Azure Artifacts проекта на Azure DevOps Services:
    • Изменения производить в отдельной ветке согласно принципам git flow. Создание втеки, все коммиты и пулл реквест должны быть привязаны к задаче Добавление зависимости от пакета chance-js требования Установка пакета chance-js в приложение.
    • Файл chance.js из папки src должен быть удален.
    • В приложение должен быть установлен пакет chance-js из “ленты” Azure Artifacts проекта.
    • При локальном запуске приложения Issues создаваться не должны, так как файл chance.js будет отсутствовать (поскольку мы пока не используем “сборщик” для приложения, файл chance.js будет “подкладываться” во время выполнения серверного билда).
    • По мере выполнения задачи ее статус должен меняться на доске. Коммиты должны быть сделаны пользователем, на которого была назначена задача. Задача после окончания работы над ней должна находиться в статусе Resolved.
    • По завершении работы над задачей должен быть создан пулл-реквест, в качестве “ревьювера” на этот пулл реквест должен быть назначен пользователь “основного” (Вашего) аккаунта. Этот пользователь должен подтвердить выполнение задачи по результатам выполнения “кодревью”. После подтверждения выполнения задачи “ревьювером” пулл реквест может быть принят.
  15. Создать билд, который будет собирать приложение из Git-репозитория в Azure Repos в виде, пригодном для публикации на GitHub Pages:
    • Можно использовать любой подходящий пул агентов.
    • В процессе выполнения билда должна выполняться команда npm run lint для запуска линтинга.
    • В билде в “результирующую” папку (drop folder), должны копироваться файлы index.html и main.js из папки src, а также файл chance.min.js из папки node_modules/chance-js/dist/. При этом файл chance.min.js должен быть переименован в chance.js в процессе копирования.
    • Continuous Integration для данного билда должен быть включен.
    • По мере создания билда статус задачи Добавление билда приложения требования Настройка CI/CD для приложения должен меняться на доске. Задача после окончания работы над ней должна находиться в статусе Resolved.
  16. Создать релиз в Azure Pipelines, который будет публиковать артефакты (“результаты”) билда приложения из закрытого Git-репозитория на GitHub Pages:
    • Создать пустой релиз в Azure Pipelines проекта.
    • В качестве артефакта для релиза выбрать билд приложения из Git-репозитория проекта в Azure Repos.
    • Создать одну стадию, в которой будет осуществляться публикация артефактов (“результатов”) билда на GitHub Pages. Стадия должна запускаться автоматически. Публикация должна осуществляться при помощи bash-скрипта, аналогичного тому, который был создан при выполнении Задания 1 данного модуля. Публикация должна осуществляться в любой Ваш личный репозиторий на GitHub в папку azure ветки gh-pages.
    • По мере создания релиза статус задачи Публикация приложения на GitHub Pages требования Настройка CI/CD для приложения должен меняться на доске. Задача после окончания работы над ней должна находиться в статусе Resolved.
    • Проверить работоспособность релиза, инициировав выполнение билда приложения.

Вспомогательные ресурсы:

  1. Официальная документация Azure DevOps.
  2. Обзор приложения Issue Tracker Demo

Вы можете