Как организовать процесс разработки в IT-компании

Управляющая платформа 1cloud постоянно развивается и совершенствуется. Мы решили поделиться с вами опытом её разработки. Несмотря на многообразие информационных технологий, некоторые подходы и методы являются универсальными. Мы не претендуем на открытие Америки, а просто хотим рассказать о том, как мы работаем.

Как разрабатывали раньше

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

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

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

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

Как разрабатывают сегодня

С развитием интернета, с увеличением его доступности и скорости доставки данных многое изменилось. Теперь нет нужны отправлять пользователю CD- или DVD-диски с дистрибутивами.

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

Сегодня если программный продукт обеспечивает возможность своего обновления через интернет (а таких подавляющее большинство), не требуется долго ждать, чтобы исправить выявленную ошибку или добавить продукту функциональности. Цикл обновления существенно сократился, а скорость разработки возросла. Это особенно заметно по публичным интернет-сервисам с веб-интерфейсом (почта, социальные сети, навигация …) или и массово используемым приложениям типа Skype, Telegram, WhatsApp.

Изменения в таких сервисах идут практически непрерывно. И занимаются ими не одиночки, а рабочие группы, состоящие из архитекторов, программистов, системных администраторов и т. д.

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

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

Всё создаёт существенные организационные трудности: нужно координировать и фиксировать работу команд разработчиков; нужно контролировать любые изменения в системе; нужно иметь возможность откатиться, если вдруг будет обнаружена критическая проблема; …

К счастью, для решения названных проблем уже имеются достаточно зрелые программные продукты. В английском языке у них есть общее название: DevOps-инструменты. Слово DevOps составлено из частей: Development (разработка) и Operations (эксплуатация).

Коллективная работа

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

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

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

Применить его можно двумя способами: установив на свой сервер отдельный экземпляр этого свободного продукта, или воспользовавшись одним из публичных Git-сервисов, например, GitHub.Com.

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

Нам не требуется распространять свой продукт, у нас имеются свои вычислительные мощности, у нас работают квалифицированные системные администраторы, поэтому мы в 1cloud.ru предпочитаем использовать собственный Git-сервер.

Учёт, контроль, дирижирование

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

Но она не обеспечивает и не может обеспечить абсолютной автоматизации. Например, если два программиста внесут изменения в один и тот же фрагмент кода, никакая автоматическая система не «поймёт», чьи изменения главнее, можно ли их передать дальше вместе, или какое-то нужно проигнорировать.

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

Утверждение изменений происходит расстановкой на них соответствующих символьных меток.

Сборка

После утверждения изменений можно приступить к тестированию системы, в целом. Для этого нужно где-то развернуть её новый экземпляр.

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

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

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

Тестирование

После сборки нового экземпляра информационной системы нужно убедиться в его общей работоспособности.

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

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

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

Выявляемые ошибки исправляются. Соответствующие изменения вносятся в git-ветку Development, и описанный цикл доработки повторяется.

Развёртывание

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

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

Следует подчеркнуть, что здесь речь идёт о нашей Панели управления виртуальной инфраструктурой, а не о самой инфраструктуре. Вычислительные ресурсы, предоставленные пользователям, функционируют на основе гипервизоров VMware, обеспечивающих доступность на уровне не ниже 99,9%. Эта величина соответствует допускаемому времени простоя виртуального сервера не более 8 часов 46 минут в год.

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

Развёртывание новой версии системы проходит в автоматическом режиме. Утверждённые изменения переносят в git-ветку Master с меткой «Утверждено». Далее Jenkins, регулярно проверяющий эту ветку, корректно копирует новые или изменённые файлы на рабочие серверы.

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

Для повышения надёжности мы сохраняем двадцать последних резервных копий рабочего экземпляра системы. При необходимости они позволят «откатить» систему не только в предыдущее состояние, но и в более ранние.

Заключение

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

Мы стараемся использовать все современные DevOps-инструменты, чтобы сделать процесс развития нашего облака 1cloud надёжным, плавным и предсказуемым.