Бесплатный онлайн-митап "Опыт применения DevOps-практик в командах разработки на 1С"

1.  Кратко о нас, нашем рабочем процессе год назад:
1.1 отдел 30+ человек, автоматизация на базе УТ11.1, внешние сервисы;
1.2 организационно: скрам, спринты, команды, работа по задачам в Trello, архитектор и код-ревью;
1.3 ПО: конфигуратор, хранилище, 1С-база для запуска скриптов, тесты на xUnit и сценарные средства 1С (тестирование именно релизной конфигурации);
2.  Что не устраивало, почему решили внедрять DevOps:
2.1 большие трудозатраты на подготовку релиза;
2.2 ошибки в релизе, приводящие к переносу релиза (у нас есть окна, когда можно обновиться), сложность определения ответственного и т.п.;
2.3 общее понимание, что требования к качеству релиза растут с ростом бизнеса, мы упираемся в существующую технологию;
3.  Что хотели получить, как себе представляли результат:
3.1 исключение из процесса подготовки релиза ручного труда;
3.2 тестирование не финального релиза, а каждого изменения в хранилище;
3.3 понимание необходимости механизма параллельного тестирования;
3.3 преимущества Гита видели исключительно в параллельной разработке, для нас не критично, поэтому, думали работать дальше с хранилищем;
3.4 EDT в таком случае тоже внедрять не имеет смысла;
4.  К чему в итоге пришли:
4.1 Гит нужен, чтобы работать с изменениями до приёма их в основную ветку (GitHub Flow);
4.2 EDT в таком случае необходим;
5  Какие программные продукты используем:
5.1 GitHub - платная версия;
5.2 TeamCity - на наших серверах, агентов не докупали;
5.3 Vanessa, Allure;
5.4 SonarQube;
6. Возникшие проблемы при внедрении:
6.1 на машинах с 4ГБ памяти работать с EDT было невозможно, пришлось обновлять;
6.2 проблема работы в связке EDT+хранилище, быстрый переход на Гит;
6.3 проблема при работе с серверными базами (серверные и большие);
6.4 проблема с отладкой в EDT на нашей инфраструктуре;
6.5 проблема с огромными фича-файлами в Ванессе;
6.6 отсутствие запрета непосредственного помещения в основную ветку в бесплатной версии ГитХаба;
7. Финальный результат:
7.1 добились поставленной цели;
7.2 примеры работы контура;
7.3 как отдел перенёс внедрение;
8. Отдельно о конфликтах в Гите:
8.1 почти полное отсутствие конфликтов у нас;
8.2 мысли об организации процессов разработки, способствующих и не способствующих конфликтам.

• Разработка в git
• Вынос менеджера обмена и правил в расширение
• Вспомогательный функционал для тестирования
• Тестирование "на месте"
• Тестирование в CI (Jenkins)
• Покрытие кода тестами
• Порог качества SonarQube как интегральная метрика принятия MR
• Достигнутые результаты и дальнейшие планы

• Полноценный конвейер на Gitlab-CI
• Merge-request для контроля качества кода
• Эталонная база как источник данных для конвейера и разработчика
• Сервер allure для хранения результатов прохождения тестов
• Автоматическое обновление рабочего контура
• Релиз функционала, который готов только частично, через функциональные опции

Доклад – исключительно практика "по горячим следам". Расскажу, как наш Gitlab CI переехал с shell-раннеров на windows-контейнеры докера. Затрону совсем немного теории,  постараюсь ответить на вопрос "Зачем?",  покажу по шагам, как прошел процесс миграции, и какие нюансы всплыли из-за использования windows. Расскажу про 3 способа запуска контейнеров, какие плюшки дает каждый способ, и как сэкономить 50Гб сетевого трафика с одного пайплайна.

Данный доклад будет полностью посвящен вопросам скорости. Предыдущий год показал, что когда компании внедряют DevOps и все необходимые инструменты – они не могут остановиться: хотят все больше и больше и в какой-то момент упираются в скорость. И тогда начинается этап переосмысления и познания. Действительно ли совсем уж ускориться нельзя? Вот про это и будет мой доклад. Я постараюсь рассказать о том, чем мы пользуемся, какие инструменты заменили и почему. А самое главное – причем тут вообще качество кода?
•  VA и мультипотоки – к чему мы пришли год спустя
•  Какие подводные камни существуют в подготовке тестовых данных, и как это связано с мультипоточностью и скоростью
•  Почему эталонные базы – зло, и куда их деть
•  Как строгая типизация кода нам может экономить время, и почему она это еще не делает
•  Что и когда лучше использовать для статического анализа кода
•  Автономный сервер – контур без лицензий, высокая скорость, кривые результаты