.NET Fest: полная программа конференции на сайте. Присоединяйся к самому большому .NET ивенту
×Закрыть

Выбор средств для обеспечения жизненного цикла решений

Всем привет! Меня зовут Стас, и я работаю на позиции Cloud Solutions Architect. Мне часто приходится инициировать старт проектов. При этом важно выбрать средства обеспечения жизненного цикла решения. Необходимо решить, какие именно средства команда будет использовать для создания, поддержки и развития решения.

Также довольно часто приходится присоединяться к проекту, который стартовали на чем было, и он имеет определенные проблемы со средствами обеспечения жизненного цикла. На таких проектах обычно нужна частичная или кардинальная смена инструментария.

По причине того, что нужно каждый раз тратить время на объяснение членам команды, что и почему будет использовано в конкретном проекте, я решил написать эту статью.

Когда предлагаете использовать какие-либо средства на конкретном проекте, будьте готовы нести персональную ответственность.

Статья в основном ориентирована на аутсорсинг, так как он составляет большую часть украинского IT, однако вполне применима и для продуктовых компаний. В основном все описанное касается mature аутсорсинг-компаний, которые ставят перед собой цели предлагать максимально качественный сервис для своих клиентов.

Многие термины специально оставлены на английском языке, так как переводить их бессмысленно.

Основные понятия

Жизненный цикл решения — совокупность стадий, которые проходит решение за период своего существования, начиная от момента возникновения идеи до утилизации.

Средства обеспечения жизненного цикла решений — совокупность программ и сервисов, которые используются членами команды в рамках жизненного цикла решений.

Категории средств

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

AreaRole
AuthЦентрализованная аутентификация и авторизация пользователей, сервисов и приложений.
Все другие средства интегрируются с этим.
CommunicationКоммуникации внутри команды.
Коммуникации на основе чатов с возможностью проведения видеозвонков и их записью, индексированием и поиском по ключевым словам.
Knowledge SharingРасшаривание знаний о проекте между всеми участниками команды.
На основе де-факто индустриального стандарта Markdown.
Requirements ManagementУправление и визуализация требованиями.
Например Scrum backlog и Kanban board.
ReposХранение исходников и контроль версий.
Например, реализация Git.
PipelinesСборка и управление выпусками.
ArtifactsХранение артефактов и работа с ними.
Например, Debug Symbols, NuGet, NPM, Maven и т. д.
TestФункциональное тестирование.
Test LoadНагрузочное тестирование.
MonitorМониторинг решения и предиктивная аналитика.
FeedbackСбор отзывов об использовании решения.
IDEСреда разработки.
Из коробки интегрированная со всеми системами.

Размещение

Обычно по условиям контрактов между заказчиком и исполнителем, которые мало кто читает, абсолютно все артефакты, порождённые во время жизненного цикла решения, принадлежат заказчику. В данном случае артефакты — это документация, требования, код, собранные приложение, тесты и т. д.

Рассмотрим следующие варианты размещения:

Размещение на стороне исполнителя (on-prem)

Плюс:

  • Некоторые инструменты могут быть уже развёрнуты и настроены.

Минусы:

    • Нужно обязательно заложить процесс передачи артефактов на сторону заказчика, а это требует идентичного набора развёрнутых сервисов на стороне клиента.
    • Крайне редки случаи, когда все инструменты есть на стороне исполнителя.
    • Затраты на лицензирование закладываются в стоимость услуг, и оплата возлагается на исполнителя.
    • Требуется организовать доступ членам команды со стороны заказчика к инфраструктуре, сервисам и системам, которые на стороне исполнителя.
    • Требуются затраты на поддержку и обновление ПО и железа.

Размещение на стороне заказчика (on-prem)

Плюсы:

  • Нет необходимости передавать артефакты.
  • Клиент сам платит за лицензии.

Минусы:

  • Крайне редки случаи, когда все инструменты есть на стороне клиента.
  • Будьте готовы к проблемам с получением доступа к инфраструктуре, системам и сервисам.
  • Требуются затраты на поддержку и обновление ПО и железа.

Размещение на третьей стороне (service)

Плюс:

  • Все артефакты принадлежат клиенту через договор оказания услуг с третьей стороной.

Минус:

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

Смешанные варианты не исключены, но, как правило, они обладают минусами всех вышеперечисленных.

Лично я всегда стараюсь продвинуть вариант использования облачных сервисов и только в исключительных ситуациях — размещение на стороне заказчика.

Средства

Есть два варианта получения набора средств:

  • собрать из разных инструментов от разных поставщиков.
  • использовать решение от одного поставщика.

Это как будто вам нужна машина, чтобы ездить, и вы можете купить её или взять в аренду и ездить сразу. Или вы можете купить запчасти, потратить огромное количество времени и денег и собрать из них пепелац.

Внимание! В этой статье я рассматриваю именно те средства и в той комбинации, которые мне больше всего встречались и с которыми у меня есть реальный опыт работы.

  • Option A — на основе сервисов и продуктов компании Atlassian, иногда упоминается как Atlassian Stack. На самом деле чаще всего используется максимум 3 продукта от Atlassian.
  • Option M — на базе сервисов и продуктов Microsoft, в основе которого лежит пакет облачных сервисов Azure DevOps. До недавнего времени являлся одним продуктом Visual Studio Team Services. Имеет версию, доступную on-prem.

Естественно, на рынке средств обеспечения жизненного цикла — много предложений. Количество возможных вариантов использования в различных комбинациях просто огромно. Однако я специально повторюсь, в статье рассматриваются именно те средства и в той комбинации, которые я лично использовал в своей профессиональной деятельности.

Хочется отдельно сказать, что даже на больших энтерпрайзных проектах бывает проблемно получить бюджет на системы для обеспечения жизненного цикла. То есть каждый месяц много тысяч денег уходят на компенсации членам команды и практически всегда начинаются вопросы про сотню-другую для оплаты средств обеспечения жизненного цикла.

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

AreaOption A ToolCostOption M ToolCost
AuthG Suit???Active Directoryfree: basic
extra: $1/user
Knowledge SharingAtlassian Confluence<10 users: $10
>10 users: $5/user
Wikifree: 5 users
extra: $6/user
Requirements ManagementAtlassian Jira<10 users: $10
>10 users: $7/user
BoardsIncluded
ReposAtlassian Bitbucket<5 users: free
>5 users: $5/user
ReposIncluded
PipelinesJenkins*1Pipelinesfree: 1
extra: $40/pipe
ArtifactsMyGet5 feeds: $40Artifactsfree: 5 users
extra: $4/user
TestGurock TestRail$30/userTest Plans$52/user
Test LoadLoad Impact$300Load Testsfree: 20k
extra: $36/100k

Некоторые Area не описаны, это сделано с целью упрощения. Потому как выбор тех же Communication средств — это тема ещё одной статьи.

Сравнение вариантов

Давайте сравним оба варианта по следующим аспектам:

Area Option A Option M
AuthИнтеграция продуктов с централизованной системой аутентификации требует дополнительных затрат.Интеграция из коробки с Active Directory и реализует B2B Collaboration.
ComplianceAtlassian заявляет о соответствии следующим требованиям: GDPR, ISO 27001, SOC 2 Type 1, CSA STAR Level 1.Microsoft заявляет о соответствии следующим требованиям: GDPR, ISO 27001:2013, SOC 1 Type 2, SOC 2 Type 2, HIPAA, BAA, EU Model Clauses.
LegalТребуется принять различные политики от каждого поставщика.Требуется принять только одну политику от одного поставщика.
Service ManagementХоть большинство сервисов управляемые, некоторые, такие как Jenkins, требуют дополнительной инфраструктуры, настройки и поддержки.Все сервисы управляемые.
TraceabilityТребуются дополнительные расходы на покупку и интеграцию плагинов.Доступна из коробки.
Price & PaymentОтдельная покупка каждого сервиса у разных поставщиков.
Отдельные счета-фактуры в конце месяца.
Совокупная стоимость владения больше, чем решение «все в одном».
Все услуги приобретаются у одного поставщика в виде пакета.
Один счёт-фактура в конце месяца.
Совокупная стоимость владения меньше, чем у отдельных систем.

Сравнение систем по функциональности систем здесь не проводим, ибо в целом системы +/- обладают одинаковой функциональностью и, например, сравнение Jira с Boards — это также отдельная тема.

Если ваш проект в регулируемом домене, например Healthcare, то желательно, чтобы абсолютно все сервисы, которые вы используете, соответствовали требованиям, специфичным в этом домене. Например, если ваш проект в домене Healthcare и территориально в USA, то вам лучше использовать только HIPAA Compliant средства.

Сценарии использования

Чтобы дать представление о приблизительной стоимости владения, ниже приведены несколько сценариев использования.

  • Stakeholders работают только с требованиями.
  • Все члены команды как минимум имеют доступ к системе тестирования для просмотра планов, кейсов и результатов.
  • Стоимость Pipeline Agents, Load Tests не включены.
  • Стоимость Option M может быть уменьшена, если члены команды имеют Visual Studio Subscription.

Scenario 1 Команда малого размера: 3 stakeholders, 5 developers, 1 tester.

Options&Tools3х stakeholder5х dev1х testTotal
Option A$350
Confluence$10
Jira$30$50$10$90
BitbucketNot Required$25$5$30
MyGetNot Required$40
TestRailNot Required$150$30$180
Option M$58
WikiIncludedIncludedIncluded$0
BoardsIncludedIncluded$6$6
ReposNot RequiredIncludedIncluded$0
ArtifactsNot RequiredIncludedNot Required$0
Test PlansNot RequiredIncluded$52$52

Scenario 2 Команда среднего размера: 5 stakeholders, 20 developers, 5 testers.

Options&Tools5х stakeholder20х dev5х testTotal
Option A$1422
Confluence$25$100$25$150
Jira$35$140$35$210
BitbucketNot Required$100$25$125
MyGetNot Required$117Not Required$117
TestRailNot Required$820
Option M$520
WikiIncludedIncludedIncluded$0
BoardsIncluded$150Included$150
ReposNot RequiredIncludedIncluded$0
ArtifactsNot Required$110Not Required$110
Test PlansNot RequiredIncluded$260$260

Заключение

Я не хочу навязывать кому-либо свое мнение. Разве что добавлю, что перед тем как выбирать какие-либо средства, основательно подумайте, проанализируйте и сравните несколько вариантов.

P. S. Надеюсь, эта статья подтолкнет людей с опытом к написанию своих материалов, раскрывающих другие аспекты средств обеспечения жизненного цикла. Например, лично я бы почитал сравнение Azure DevOps с GitLab Cloud.

LinkedIn

6 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Помню когда-то давно чуть ли не в прошлом тысячелетии отказались от использования стэка МС потому что их система контроля версий Линукс поддерживала чуть хуже чем никак, при том требовала Windows Server, а веб-интерфейсы требовали IE. Как сейчас с этим, можно ли использовать их стэк ничего не зная о Windows?

С 2013 года MS предлагает стандартную реализацию git.
Единственное неудобство пользователям не win based систем — необходимость сгенерировать себе доп ключи доступа.
Пользователи windows могут получать доступ к git используя SSO с учеткой под которой они зашли в операционную систему.

В случае Option A для аутентификации, как вариант, ещё можно использовать Atlassian Crowde

Насправді варіантів багато. Стаття більше схожа на рекламу Option M.

Читая подумал что уже кажется всё это слышал на AzureDay, особенно на словах про HIPAA Compliance. Потом только обратил внимание кто автор :) Спасибо и за доклад, и за эту текстовую версию!

Подписаться на комментарии