 |
|
|
|
CI/CD для 1С
CI/CD для 1С Если вы хотите использовать лучшие практики, применяемые крупными командами при разработке на 1С, эта статья может оказаться весьма полезной Заголовок этой статьи может оставить двоякое мнение: или совсем непонятно, о чем речь, или понятно, но не ясно при чем тут 1С. К сожалению, с терминологией CI/CD знакомы далеко не все, даже в среде разработчиков. Поэтому в первой части статьи будет немного теории по вопросам, что это такое и для чего оно нужно. Но сначала немного разберемся, почему на первый взгляд применительно к 1С процессы CI/CD кажутся неуместными:
В этом, конечно, есть зерно истины – для 1С выгода от применения процессов CI/CD будет намного меньше, чем для команд разработки на традиционных языках программирования, особенно если эти команды разрабатывают приложения на C++/Python/Ruby, т.е. на языках программирования, приложения на которых трудно представить не модульными. Тем не менее CI/CD – это не набор средств и инструментариев, это набор процессов, основные принципы которых не зависят от того, для чего и в какой среде они используются. CI – Continuous Integration (непрерывная интеграция) – суть этого процесса заключается в том, что должна существовать единая среда, где постоянно объединяются все изменения команды разработчиков, которые они вносят в систему контроля версий. Да, кстати, система контроля версий при этом должна существовать. Если ее нет, то вообще непонятно, какведется разработка и как она управляется. Разработчик 1С, конечно, не может работать совместно с другим разработчиком над одним и тем же модулем. VCS, встроенная вплатформу, это запрещает. Но никто не запрещает иметь, к примеру, два хранилища (ну или три или более – по желанию), в которых будут отдельные ветки кода. В этом случае сервер сборок будет еще нужнее. В базе разработчика платформой 1С не гарантируется наличие всего кода, который в данный момент коммитят другие члены команды. CD – Continuous Delivery (непрерывная доставка) – суть данного подхода заключается в том, что любые изменения, сделанные разработчиками в процессе работы над проектом, должны попадать к конечному пользователю максимально быстро и беспроблемно. Очень редко процессы Continuous Delivery рассматривают отдельно от процессов Continuous Integration. Часто даже сами разработчики путаются и представляют себе это как одно и то же: «я закоммитил изменение – оно должно протестироваться и успешно собраться – этоназывают CI/CD». На самом деле в рамках CD речь идет уже несколько дальше. Процессы CD должны обеспечить именно «доставку» ПО до конечного пользователя. Выражаясь русским языком, любая сборка, которая появилась на сервере сборок, должна иметь возможность тут же отправиться в Production, и в течение незначительного времени эту сборку получат все пользователи разрабатываемого ПО. При этом идеальный вариант, если пользователь даже не заметит, что у него уже новая версия данного программного продукта, и сбагами, обнаруженными в старой версии, он просто столкнуться не успел. Не вижу никаких причин не применять этот подход к 1С, особенно если речь идет о поддержке филиальной сети, распределенной информационной базы или чего-то в этом роде. Теперь попробуем перейти от слов к делу. Из теории ясно, что CI/CD подразумевает сервер сборок и развертывания, на котором будет автоматически происходить достаточно много процессов, поддерживающих циклы разработки ПО. Для разработчика же практически ничего поменяться не должно, кроме регулярных сообщений, что в его коммите обнаружен баг. Классическая картинка, демонстрирующая, какие процессы входят в CI/CD, представлена на рис. 1.
Рисунок 1. Последовательность процессов CI/CD Теперь давайте рассмотрим, какие из этих процессов применимы к 1С и как мы можем их автоматизировать на сервере сборок. Как правило, на практике CI/CD приобретают следующий вид:
Данные процессы планировались прежде всего для команд разработки на универсальных языках программирования, но это не значит, что они совсем не применимы к 1С. Нужно просто учитывать некоторую специфику. Фразы вроде «это не для 1С» или «у нас нет крупной разработки» в современном мире звучат больше как отговорки. Определенные трудности и потребность в адаптации даже не столько процессов, а средств их автоматизации – совсем не повод отказываться от Best Practice современных подходов к разработке иподдержке жизненного цикла ПО. Далее по каждому пункту разберемся отдельно. Статью целиком читайте в журнале «Системный администратор», №6 за 2017 г. на страницах 52-55. PDF-версию данного номера можно приобрести в нашем магазине.
|
ОЛЕГ ФИЛИППОВ, АНТ-Информ, заместитель начальника отдела разработки, 
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
