Ниже описаны правила и средства взаимодействия между CSI и внешними разработчиками.

Внешней команде разработчиков со стороны CSI выделяется Product Owner (далее - PO или владелец продукта).
PO предоставляет команде разработки пользовательские истории или функциональные сценарии.
Назначает процесс работы (Scrum, Kanban), сроки выполнения задач, размеры итераций.
PO принимает выполненные работы, принимает решение об их готовности, завершённости.

Пользовательские истории / функциональные сценарии

Пользовательские истории (user stories) должны содержать:

понятное описание требуемого функционала;
сценарии использования (use cases), по которым выполняется демонстрация, приёмка выполненной работы и написание автоматизированных функциональных тестов;
нефункциональные требования

Команда разработки приступает к выполнению задач, только после полного понимания пользовательской истории / функциональных сценариев.
Необходимые ответы на вопросы и уточнения могут вноситься перед началом выполнения работ.
Пользовательские истории ведутся в Jira.

Jira

CSI может предоставить внешним разработчикам доступ к Jira на время выполнения работ.
В этом случае разработчики, тестировщики своевременно меняют статус работ в Jira (ToDo, In progress, Test, Ready и т.п.)

Размещение документации в Confluence

CSI может предоставить внешним разработчикам доступ к Confluence на время выполнения работ.
При необходимости документирования готового функционала - публикуются статьи в соответствующем пространстве Confluence.

Jenkins

Запуск сборок, статического анализа кода, unit и функциональных тестов происходит в Jenkins на стороне CSI
При подготовке к разработке DevOps команда CSI подготавливает необходимые ресурсы и создает заготовки Jenkinsfile (файлы с описанием процесса сборки и тестирования продукта).
Изменение Jenkinsfile может производиться аутсорс-разработчиками или DevOps на стороне CSI (обговаривается при старте проекта)

Инфраструктура для тестовых и демонстрационных стендов может быть предоставлена CSI по требованию.
Требования к инфраструктуре определяются на этапе согласования проекта.

GitHub

CSI предоставляет разработчикам доступ в приватный репозиторий, мастер ветка защищается от push.
Попадание в мастер ветку происходит только через pull request.
CSI готовит шаблон требований к pull request в репозитории.
Пример шаблона:

### Задача
[Ссылка на задачу]()

### Краткое описание задачи

### Качество
- [ ] Тестовые сценарии
- [ ] Unit-тесты
- [ ] Функциональные тесты - [Ссылка на прогон]()
- [ ] Статический анализ
- [ ] Документация в Confluence
- [ ] Проверка нефункциональных требований
### Приёмка
- [ ] Принято CSI

Наименование веток и комментарии к комитам должны содержать краткий код пользовательской истории.
Это необходимо для интеграции Jira и GitHub, например из пользовательской истории можно перейти к pull request и посмотреть изменения в коде.

Code style

Codestyle manifest

Intellij IDEA codestyle

Eclipse codestyle

Eclipse import order

Статический анализ кода SonarQube

При старте проекта DevOps CSI добавляют репозиторий в SonarQube на стороне CSI

Code review

Разработчики назначают ревьюверов в pull request.
Ревьюверы должны проставить статус approve или попросить устранить найденные замечания.
Разработчики должны устранить указанные замечания в коде.

Список возможных участников Code review определяется перед стартом проекта
SLA проведения Code Review определяется перед стартом проекта

Фреймворки для автоматизированного тестирования

Аутсорс-разработчикам передаются инструменты для автоматизированного тестирования продуктов CSI.
По инструментам оказывается консультативная помощь и доработка.

TestRail

Сценарии использования функциональности по каждой из задач заносятся PO в систему TestRail и прикрепляются к задаче в Jira.
Внешние разработчики имеют доступ к системе TestRail.

Outsource:

Developing

Разрабочики пишут код в соответствии code style manifest.
Для сборки Java-проектов используется gradle.

Разработчики самостоятельно пишут gradle-файл.

Unit tests

Разработчики пишут юнит тесты.
Измерение покрытия кода тестами осуществляется Jacoco.
Покрытие кода (среднее от показателей BRANCH + LINE) должно быть не менее 60%.

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

Автоматизированные функциональные тесты

Разработчики реализуют автоматизированные функциональные тесты, покрывающие сценарии использования, предоставленные PO вместе с задачей.
Результат выполнения автоматизированных тестов контролируется при помощи Jenkins на стороне CSI.

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

Функциональные тесты должны быть независимыми и изолированными от внешних ресурсов (сервера, оборудование и т.п.)
Функциональные тесты должны взаимодействовать с эмуляторами внешних сервисов.
Эмуляторы должны быть реализованы самостоятельно или в качестве расширения для WireMock.

Кассовые плагины Set Retail 10 должны иметь отдельные функциональные тесты для специализированного кассового фреймворка.

Функциональные тесты запускаются в Jenkins на стороне CSI.
Требуемая инфраструктура обеспечивается DevOps-командой CSI.

При отсутствии функциональных тестов или их падении задача не считается выполненной.

Разбор и устранение замечаний системы статического анализа кода

Разработчики должны разобрать и устранить замечания уровней Critical и Blocker от системы статического анализа кода SonarQube.

Без исправления Critical и Blocker замечаний задача не считается выполненной.

Документация

В требованиях пользовательской истории или в момент приёмки работ Proudct Owner может потребовать составить техническую документацию (API, способы эксплуатации, скрытые настройки, способ мониторинга и т.п.)
Документация готовится разработчиками и публикуется в соответствующем пространстве в Confluence CSI.