DevOps. Как это выглядит у нас

Публикация № 1129248

Методология - DevOps

DevOps администрирование менеджмент

47
DevOps в департаменте разработки 1С в крупной компании.

В июне этого года мне предложили выступить на конференции. Тайминг был 25 минут, поэтому я подготовил выступление из двух частей, первая - о проекте, а вторая - о том, как мы понимаем и используем DevOps. В самый последний момент время на выступление сократили в два раза, из-за чего я рассказал только первую часть, а вторая пылилась на яндекс-диске. Сейчас, разбирая залежи я случайно наткнулся на презентацию и расшифровку, которую планировал читать. Не пропадать же добру? Наверное статья кому-то покажется сырой, ведь фактически формат предполагал быстренько рассказать "а как у нас", а потом уже в кулуарах обсудить детали. Кто-то попрекал меня, что я превращаю инфостарт в личный дневник. Пожалуйста, закройте страницу и не читайте дальше. Дальше будет жесткое IMHO!
Так как изначально это была презентация - я сохраню формат, сначала слайд - потом текст.

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

Интеграция команд 

Начнем с определения взятого с википедии: 

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

Бизнес заводит Запрос на изменение в специальной системе, так называемый RFC. RFC поступает к владельцу продукта. Все приложение поделено на 5 условных частей и есть соответственно 5 scrum-команд: 

  • Продажи 

  • Товародвижение 

  • B2B 

  • Дилеры 

  • Интернет-магазин. 

Что значит эти команды и чем занимаются для нашего рассказа не важно, не буду заострять на этом внимание. Итак, задача поступает к владельцу продукта, он ставит ее в беклог. Каждые две недели выполняется так называемый грумминг, когда RFC делятся на мелкие задачи, которые можно поручить одному человеку, будь то бизнес-аналитик, разработчик, тестировщик или администратор. Администраторы, кстати не относятся ни к какой команде, а привлекаются по мере необходимости. Затем уже прогрумленные задачи включаются в спринт. Таким образом в спринт может, например войти – «провести анализ по RFC», следовательно над задачей уже работают, но в релиз она не войдет. По окончании разработки, но до передачи задачи в тестирование проводится УАТ, приемочное тестирование, на котором заказчик смотрит, что сделали именно то, что он хотел. В УАТ обязательно участвует сотрудник технической поддержки и как раз вот этот момент – это чистый DevOps. Сотрудник техподдержки так же как и заказчик может сразу высказать свои замечания, например сообщить, что вот эти моменты нужно переделать, здесь обязательно добавить логирование, уточнить по планируемой нагрузке на систему в условных попугаях и дать предположение о необходимости оптимизации решения ДО его выпуска в продуктив. 

Перед выпуском релиза команда сообщает список задач, которые готовы к выпуску в релиз и помещает весь готовый к выпуску в продуктив код в релизное хранилище. Я не буду тут углубляться в технические детали, сколько у нас хранилищ, кто и когда помещает в них код, это для данной темы не очень важно. После сборки релиза все тестировщики перестают быть членами скрам-команд и превращаются в команду тестировщиков. Начинается регрессионное тестирование. На текущий момент оно длится около полутора дней и состоит примерно из 240 регрессионных тестов. По окончании регрессионного тестирования принимается решение о выпуске релиза. После выпуска релиза свою работу начинает техподдержка, анализируются основные показатели работоспособности системы, такие как APDEX, нагрузка на систему, анализ технологического журнала на количество эксепшенов, время ожиданий на блокировках и еще несколько десятков параметров. Кроме того внимательно изучаются все поступающие инциденты. На основании полученных данных заводятся дефекты с критичностью от 1 до 4, где 1 – полная остановка системы в результате дефекта, а 4 – есть ошибка на неосновном функционале имеющая обходное решение. 

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

СI/CD. 

Священная корова DevOps. 

Начнем с неприятного. Мы не используем EDT. Причины со сцены я озвучивать не буду. Примем как данность. Значит у нас нет гита. 

Continuous Integration.  

У нас нет автоматической сборки проекта, однако часть CI присутствует. На проекте работают 12-15 разработчиков, которые ежедневно, а иногда и несколько раз в день помещают свой код в хранилище разработки, из которой уже обновляются базы, в которых работают тестировщики. Статистика показала, что в день проходит примерно 20-40 таких пул-реквестов. 5-10 раз в сутки основная база для тестирования обновляется из хранилища разработки. Каждую ночь запускаются автотесты, по результатам выполнения которых тестировщики заводят дефекты. Пока вручную. Можно ли считать это непрерывной сборкой? Считаю что да. 

Continuous Delivery. 

Тут сложней. Несмотря на то, что динамическое обновление присутствует в 1С уже очень давно – мы его не используем. К счастью, 1С придумала расширения. Одной из самых важных причин перехода с 8.3.10 на 8.3.12 было исправление ошибок по работе с расширениями. На текущий момент все дефекты более-менее высокого приоритета исправляются расширением, новый функционал не выпускается расширениями только из-за бюрократических препон. Технических ограничений выпускать новый функционал по мере готовности никаких нет. 

Automated Testing 

Процесс обкладывания кода автотестами в среде 1С несильно распространен, поэтому данная практика оказалась одной из самых сложных в проекте. Однако опыт, накопленный «Серебряной пулей» позволил нам в течение 3 месяцев подготовить стенд и обучить сотрудников группы тестирования созданию автотестов. На текущий момент порядка 220 кейсов обложены автотестами (см. выше), кроме того после выхода новых задач появляются кейсы в регрессионном тесте, которые так же кладутся в скоуп задач по созданию автотестов. По мере возможности тестировщики берут и разрабатывают автотест для конкретных кейсов. 

Внедрение автотестирования позволило сократить регрессионное тестирование перед выпуском релиза с 90 до 35 человекочасов (с 1.5 до 0.5 рабочего дня при участии 7 тестировщиков) 

Инфраструктура как код (Infrastructure as Code) 

На текущий момент не используется. 

Continuous Deployment 

Не так давно (меньше года назад) 1С представила свой новый продукт: «Центр администрирования». Он позволяет автоматизировать то, что раньше делалось вручную, писались разрозненные скрипты или использовались продукты других компаний. На текущий момент Центр администрирования встроен в Центр контроля качества, который мы активно используем в качестве CMDB и системы мониторинга, поэтому сразу после появления данного продукта наши администраторы начали менять свои самописные скрипты на сценарии в данном продукте. На текущий момент уже выполнена автоматизация установки продуктивного релиза которая включает в себя блокировку базы, перезапуск служб и очистку сеансовых данных, подключение к релизному хранилищу и обновление основной и конфигурации базы данных. Участие человека сводится к запуску скрипта, которая нужна лишь для соблюдения регламента компании. 

Load Testing 

Для проведения нагрузочного тестирования есть специальный стенд, состоящий из 6 физических серверов, полностью повторяющих продуктивную среду. После того, как релиз-менеджер дает отмашку о готовности релиза конфигурация, полностью соответствующая той, что выйдет в продуктив устанавливается на нагрузочный стенд, после чего в течение 6-8 часов 8 тысяч клиентских сессий эмулируют типовую нагрузку на систему, пробивают чеки, проводят накладные на поступление товара и прочее. По итогу нагрузочного теста формируется сводная оценка APDEX согласно методике, рекомендованной компанией 1С. Оценка считается от 0 до 1, где 1 – падения производительности не зафиксировано, а 0 – система фактически не работоспособна. На основании полученной оценке принимается решение о выпуске релиза. 

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

Application Performance Monitoring 

В системе регистрируется время всех основных операций, на текущий момент их около 40. По каждой из операций с бизнес-подразделениями компании заключен формальный договор, какое среднее время операции считать хорошим, какое приемлемым, а какое плохим. Мониторинг в системе настроен таким образом, что если время какой-либо операции отклоняется от «хороших» значений об этом немедленно оповещаются администраторы и в системе ServiceDesk заводится инцидент. В зависимости от количества операций и от степени их отклонения от нормы приоритет инцидента может быть повышен вплоть до критического (система недоступна для работы). 

Выводы

Несомненно разработка в 1С накладывает определенные ограничения для использования современных технологий разработки, однако все эти технологии имеют несколько вариантов прочтения и прикрыв глаза ладошками можно гордо заявить - мы внедрили DevOps :)

47

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. genayo 01.10.19 08:15 Сейчас в теме
Вопрос несколько не по теме - а ни разу не пожалели, что 1С для такого крупного проекта выбрали? И интересно было бы узнать причины, почему именно 1С :)
smit1c; chg; zabaluev; +3 3 Ответить
6. Repich 356 01.10.19 12:22 Сейчас в теме
(1) Нет. Нам требовалось решение с возможностью дешевых и быстрых доработок. Ни SAP и Oracle таких вариантов не предоставляют. SCRUM это не про них.
7. genayo 01.10.19 12:26 Сейчас в теме
(6) Интересно, кроме SAP Oracle и 1С вообще ничего не рассматривали? Самостоятельная разработка на JAVA или Net вообще не вариант?
8. Repich 356 01.10.19 13:09 Сейчас в теме
(7) Нет, эти варианты не рассматривались.
10. acanta 67 01.10.19 16:21 Сейчас в теме
Тело не живёт без мозга (с)
Какое СУБД или какие форматы бд есть у Java?
sasha777666; +1 Ответить
11. genayo 01.10.19 18:26 Сейчас в теме
(10) Мы обсуждаем не универсальное, а специализированное решение :))
2. Pr-Mex 123 01.10.19 09:11 Сейчас в теме
Дорогу осилит идущий!
3. botokash 80 01.10.19 09:32 Сейчас в теме
например мы по закону не имеем права предоставлять разработчикам доступ в продуктивную систему, а так же сотрудник, который пишет код – не имеет права самостоятельно его тестировать


А можете прояснить данный момент, что за законы?
sasha777666; user1233595; утюгчеловек; +3 Ответить
4. GreenDragon 01.10.19 10:52 Сейчас в теме
(3) Предположу, что закон о персональных данных
5. Repich 356 01.10.19 12:20 Сейчас в теме
9. Summer_13 01.10.19 15:47 Сейчас в теме
"Несмотря на то, что динамическое обновление присутствует в 1С уже очень давно – мы его не используем"
Сразу можно ставить плюс =)) Постоянно наблюдал и наблюдаю ,как с течением времени отваливаются базы у разработчиков,которые используют динамическое обновление.
12. OPM 116 10.10.19 10:43 Сейчас в теме
(9) Периодически использую динамическое обновление, и ничего - базы работают, главное не забывать делать обновление в монопольном режиме. p.s. от передоза соли тоже можно умереть, ты же не выбрасываешь солонку?
13. Summer_13 10.10.19 11:59 Сейчас в теме
(12) Какой смысл в динамическом обновлении,если Вы можете делать обновление конфигурации в монопольном режиме?
14. OPM 116 10.10.19 16:12 Сейчас в теме
(13) Если для вас норма выкидывать всех из базы в середине рабочего дня - то не вопрос, можно делать только в монопольном, пользователи подождут.
Но чаще всего бизнес не хочет останавливаться, вот здесь и решаешь или пользователи ждут до следующего дня, или динамическое обновление.
Я против того, чтобы обновлять бездумно раз 10 на дню, но говорить, что это абсолютное зло неправильно.
Иногда запрещают использовать динамическое обновление - чтобы не было ситуации когда один попросил и обосновал, второй, третий, и не каждому откажешь, а потом база легла, в этом случае проще запретить для всех, чем разгребать обиды: почему для одного обновили, а второму нет.
15. Summer_13 10.10.19 16:23 Сейчас в теме
(14)Так это Вы же делаете в монопольном режиме "главное не забывать делать обновление в монопольном режиме",как у вас в этот момент работают пользователи? А если Вы всех выгоняете -зачем делать обновление динамическим?
16. OPM 116 10.10.19 16:26 Сейчас в теме
(15)Вечером делаешь в монопольном или в выходные (когда есть окно для обслуживания), когда нет никого.
Оставьте свое сообщение

См. также

Vanessa, хочу все и сразу 97

Статья Программист Бизнес-аналитик Руководитель проекта Нет файла v8 Бесплатно (free) Vanessa Automation

Vanessa Automation это инструмент для тестирования прикладных решений на платформе 1С, но он/она может больше, чем только тестирование.

11.10.2019    3005    OPM    9       

Сказ про то, как я DevOps-ом занимался (OneScript, Deployka, Jenkins) 112

Статья Системный администратор Программист Нет файла v8 1cv8.cf ИТ-компания Бесплатно (free) OneScript DevOps Jenkins

Решаем задачу: автоматизировать обновление тестовых баз 1С из хранилища конфигурации при появлении в нём новых изменений. Данная статья родилась в муках хождения по граблям и поиска безопасного форватора среди подводных камней. Изложение постарался представить в виде инструкции для новичка, в которой собрал всё, с чем пришлось столкнуться. Сам я не DevOps-ер, ни на что не претендую, просто делюсь опытом :)

17.06.2018    14901    stas_ganiev    33       

Запуск Apache 2.4 с модулем 1С внутри Docker контейнера 87

Статья Системный администратор Программист Нет файла v8 Linux Бесплатно (free) Администрирование данных 1С WEB docker Apache

Про Apache и про Linux слышали, наверное, все. А вот про Docker пока нет, но он сильно набирает популярность последнее время и не зря. Поделюсь своим опытом и дам пошаговую инструкцию настройки веб-сервера Apache с модулем 1С внутри Docker контейнера на Linux хосте. При этом сам сервер 1С может находиться совсем на другой машине и на другой операционной системе. Это не важно, главное чтобы Apache смог достучаться до сервера 1С по TCP. В статье дам подробное пояснение по каждой используемой команде со ссылками на документацию по Docker, чтобы не создавалось ощущение непонятной магии. Также прилагаю git репозиторий с описанием всей конфигурации, можете попробовать развернуть у себя буквально за 10 минут.

04.04.2018    17796    petr.myazin    35