Проектирование и разработка Pandora FMS

Pandora FMS началась как полностью личный Opensource проект в 2004 году. Я даже не был профессиональным программистом, я был консультантом по безопасности Unix. На самом деле, я выбрал PHP, но Pandora FMS была моим первым приложением на PHP, я знал немного ASP, а моим любимым языком программирования был C.

Проект, в котором работает всего один программист и еще нет ни одного профессионального пользователя его программного обеспечения, сильно отличается от проекта с несколькими десятками программистов и сотнями клиентов, использующих программное обеспечение в критических условиях. Эволюция, которую прошла система Pandora FMS с 2004 по 2021 год, является реальным примером непрерывного совершенствования процесса разработки программного обеспечения.

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

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

Система контроля версий

Это неотъемлемая часть любого программного проекта. Сегодня вездесущий GIT у всех на устах (кстати, не все знают, что Git – детище Линуса Торвальдса, автора ядра Linux). Одним словом, система контроля версий позволяет группе разработчиков работать, не наступая друг другу на пятки.

Когда начинался проект Pandora FMS, я работал без контроля версий, потому что других людей не было. Когда некоторые люди начали работать над ним, мы поняли, что простого общего каталога недостаточно, потому что мы наступали на код друг друга и, да, делать резервные копии для сохранения старых версий было не очень эффективным методом.

Первой системой контроля версий, которую мы использовали, была CVS, которую мы использовали в течение восьми лет или более. Примерно в 2008 году мы начали использовать SVN(Subversion), другую, чуть более эффективную систему, и только в 2013 году мы начали использовать GIT и открыли наш официальный репозиторий на Github.

Публичный репозиторий Pandora FMS на Github

Поскольку Pandora FMS имеет часть с открытым исходным кодом и часть Enterprise – с закрытым исходным кодом и коммерческой лицензией – у нас есть два GIT-проекта, один публичный на GitHub, а другой частный, которым мы управляем с помощью GitLab. Версия на GitHub синхронизируется с нашей личной копией в GitLab в нашем офисе. Это частное хранилище доступно некоторым партнерам, с которыми мы ведем совместные разработки, и через расширение нашего приложения поддержки (Pandora ITSM) мы разделяем все билеты по планированию разработки, для релизов с некоторыми из НАШИ ПАРТНЕРЫТеперь проект доступен в режиме реального времени, так что вы можете видеть в реальном времени планирование развития на основе релизов и все детали каждого тикета.

Представление билетов GitLab в Pandora ITSM

Вид билета на выпуск

Методология разработки, используемая в Pandora FMS

В Pandora FMS мы с самого начала использовали собственную методологию, хотя многие идеи мы позаимствовали из agile-методологий, особенно SCRUM. С точки зрения жизненного цикла мы используем адаптацию методологииRolling Release.

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

Цели рабочей методологии Pandora FMS

В число целей входят не только сотрудники отдела разработки, но и Q/A, группа документации и часть маркетинговой группы:

• Максимальная визуализация: вся команда должна видеть одну и ту же информацию, и она должна поступать снизу вверх и сверху вниз. Разделяя цели, мы сможем работать более эффективно.
• То, что не видно, не существует, что подразумевает, что вся информация, имеющая отношение к проекту, должна быть отражена в управлении, реализованном с помощью Gitlab. То, что не видно, не существует, а то, что не существует, не будет принято во внимание ни для какой цели. Строгое следование этой методологии позволит всем очень осознанно подходить к планированию: – Строгое соблюдение сроков.Предварительное планирование без изменений в последнюю минуту.-Более четкая и своевременная информация.

  -Ограничение пиковых нагрузок и так далее.

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

Билет

Билет – это минимальная единица работы. Планируется, что она будет выполнена одним человеком, и ее планируется выполнить за один этап (выпуск версии).

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

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

Заполненный билет должен вести себя так, как указано в функциональном документе (билете), а изменения, внесенные в эти спецификации, должны быть отражены в билете.

Функционал является ключевым для Q/A, чтобы подтвердить билет или нет. Q/A будет вынужден повторно открыть билет, если он не соответствует какому-либо аспекту функционала.

Члены и рабочие группы

Владелец продукта (PO)

Он определяет, куда должна двигаться Pandora FMS, контактируя с клиентами, службой поддержки и “реальной” рыночной ситуацией, предоставляя технические и функциональные рекомендации, но не участвуя в разработке как таковой.

Комитет по продукции

Группа людей, которые будут постоянно встречаться с PO для согласования того, куда движется продукт, пытаясь сделать все решения PO коллегиальными. Она состоит из руководителя каждой команды разработки, Q/A, поддержки, проектов и документации.

Менеджер по развитию (DM)

Он будет управлять всем циклом разработки: определять этапы, приоритеты, индивидуально управлять всеми участниками и принимать оперативные решения. Он подчиняется исключительно PO и является лидером команды разработчиков.

Команда разработчиков

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

Q/A оборудование

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

Команда поддержки

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

Команда проекта

Они реализуют конечного клиента и находятся ближе всего к клиенту, так как часто бывают там еще до того, как проект существует, и обычно приносят идеи и функциональные возможности всех видов, во всех смыслах они являются “громкоговорителем” коммерческого отдела, именно поэтому они входят в комитет по продукту.

Команда по обучению и документированию

Отвечает за обучение и документацию по продукции. Они координируют свою работу с командой маркетинга и командой переводчиков.

Телеработа

Все члены команды (разработка, Q/A, документация) свободно работают на дому. На самом деле, в Pandora FMS участвуют разработчики из Европы, Азии и Америки, а в Испании они распространены по всей территории страны. Мы являемся 100% распределенной и децентрализованной компанией, хотя и с традиционной иерархией.

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

Охранники развития

Один разработчик в команде специально занимается решением вопросов, связанных с кодом, находясь в постоянной связи со службой поддержки (с 8.00 до 20.00, CEST). Это не только обеспечивает максимальную оперативность в решении проблемы клиента, но и позволяет интегрировать изменения кода в репозиторий кода организованным образом.

Процесс создания и сортировки билетов

Любой сотрудник компании (включая сотрудников отдела продаж) может создать тикет в GitLab. Сюда входят клиенты и партнеры, хотя в их случае существует предварительная фильтрация службой поддержки и коммерческим отделом соответственно.

Чем подробнее билет, тем однозначнее развитие. Добавьте изображения, gif-файлы, анимацию и все необходимые пояснения. А также как получить доступ к среде, в которой возникла проблема, или к контактным лицам. Разработчик никогда не будет связываться с клиентом напрямую. Если вам необходимо взаимодействовать с ним, это будет сделано через службу поддержки или команду проекта.

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

Когда тикет завершен и разработчик считает, что коллега должен его просмотреть, он/она упоминает об этом в запросе на слияние через @xxxxx. Обзор должен быть номинальным. Этот обзор не зависит от обзора кода, проводимого менеджером отдела.

Общий порядок работы с билетами.

• Билет назначается программисту ДУ. Если для него не назначен билет, он сам назначит билет. (Условия, регулирующие этот механизм, см. ниже).
• Разработчик должен понять / разрешить любые сомнения, которые могут возникнуть после прочтения функционального документа, при необходимости проконсультироваться с DM или автором тикета. Это должно быть сделано до начала разработки. Прочитав ее, вы должны, по порядку:

1. Оценить (путем присвоения меток) их сложность и размер, достигнув предварительного консенсуса с ДМ.
2. Разработка функциональности в соответствии со спецификациями билетов.
3. Документируйте все разработки в том же билете или, если требуется, в новом билете документации. Этот билет должен быть связан с “родительским” билетом по #ID билета.
4. Разработчик должен проверить его функциональность, по крайней мере, на:
   -стандартная среда разработки docker
   среда разработки -docker с данными.

• Когда работа будет признана завершенной, она будет помечена как “Ожидание Q/A” и передана в руки Q/A.
• Для каждого тикета типа FUNCTIONALITY будет определен референт, обычно из проектов, поддержки или даже самого PO. Именно этот человек будет определять часть функционала (вместе с DM и PO), но прежде всего, он/она будет референтным лицом для разработчика, у которого можно спросить о любой детали во время разработки, и, самое главное, он/она будет тем, кому нужно будет показывать ход разработки, шаг за шагом, чтобы он/она мог подтвердить его.
• Любые изменения в функционале будут отражены референтом в тикете в виде комментариев, без изменения исходного функционала.
• Если есть дочерний билет на документацию, Q/A будет проверять билет, используя документацию, созданную референтным лицом, а НЕ функциональным лицом билета, проверяя как документацию, так и функциональность.

Планирование выпуска

При создании билета веха должна быть пустой (не назначенной), так же как и пользователь. Классифицировать билет могут только: ДМ и ДО.

Для поддержки процесса классификации билетов был определен ряд вех, некоторые из них, те, которые имеют дату (релизы), можно рассматривать как вехи, в то время как остальные следует рассматривать как простые контейнеры для билетов.

• (Не назначен): Это отсутствие вехи на билете. Для всех намерений и целей этот билет “еще не существует”. DM и PO будут проверять каждый из этих билетов, чтобы понять, имеют ли они смысл в дорожной карте продукта. Ни один разработчик не должен брать ни один из этих билетов.
• Feature backlog: билеты, которые будут сделаны в какой-то неопределенный момент в будущем и которые рано или поздно придется решать. Ни один разработчик не должен брать ни один из этих билетов.
• Ошибки с низким приоритетом: Сообщаемые ошибки с приоритетом, который еще не присвоен PO/DM. Ни один разработчик не должен брать ни один из этих билетов.
• СТАДИЯ: Билеты, предлагаемые каждым отделом для планирования в релизе продукта. На каждой встрече по планированию эти билеты будут обсуждаться и переноситься на другие вехи. В конце стартовой встречи эта веха должна быть пустой. DM принимает окончательное решение о том, какие билеты STAGE войдут в релиз, а какие нет, при необходимости опираясь на комитет по продукту. Ни один разработчик не должен брать ни один из этих билетов.
• XXX: Освобождение XXX. Веха, объединяющая серию билетов, которые должны быть выпущены в определенную дату. С вехой связан определенный срок. В случае релизов RRR эта дата является скользящей, в случае релизов LTS – нет.

1. Разработка билетов, связанных с релизом, должна быть завершена за 5 дней до запланированной даты релиза. Билеты, не завершенные до этой даты, будут перенесены на следующий выпуск, а задержка должна быть обоснована DM.
2. Существует два типа вех выпуска:
3. LTS: в апреле и ноябре. У них разница в 6 месяцев.
   Регулярные выпуски (RRR): между выпусками LTS будет выпущено от 2 до 4 регулярных выпусков.

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

CICD

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

Эти тесты выполняются динамически на серии прогонов, некоторые из которых специфичны для определенных архитектур (например, ARM), которые запускают статические анализаторы кода, модульные тесты и подтягивают контейнеры для выполнения интеграционных тестов на реальной установке приложения.

Формирование пакетов Pandora FMS полностью автоматизировано. Каждый вечер из ветки разработки создаются пакеты для ручного тестирования. Они также могут быть созданы по требованию любого разработчика или члена команды Q/A или поддержки из любой ветки через веб-интерфейс GitLab.

При выпуске релиза из стабильной ветки, помимо создания пакетов, выполняется ряд шагов, которые разворачивают их на внутренний сервер пакетов Arctica, на SourceForge, в среду поддержки клиентов Arctica, а также обновляют репозитории Debian, SUSE и CentOS вместе с официальными образами Docker.