devops, CI/CD и вот это все, кто-нибудь исповедует/практикует?

А пофиг куда тратить дешёвую рабсилу - на написание тестов или на ручное тестирование, хехе

У вас тесты пишет дешевая рабочая сила?

У нас разрабы пишут свои юнит тесты, потом автотестеры пишут свои автотесты, а потом ручники делают свои ручные тесты.

потом автотестеры пишут свои автотесты

что такое «автотесты»?

У продукта есть разные апи и требования к ним. Автотесты проверяют, что ничего старого не отвалилось после запиливания новых фич.

Вообще, что ты перечислил это инструменты для решения задач. Какую задачу ты хочешь решить? Ну и цель тоже желательна.

Линтеры, например, как самое малое.

У нас такого нет. Есть документация, требования и диалог с разрабами. В код продукта никто не лазиит со стороны тестирования.

Линтеры документации, которые проверяют битые ссылки, например. Выкатил в репу кусок доки, запустились тесты.

битые ссылки

Куда должна вести ссылка в документации?

https://github.com/werf/website/pull/457/checks

Как-то вот так.

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

Автотесты проверяют, что ничего старого не отвалилось после запиливания новых фич.

это называется «регрессионные тесты»

Линтеры, например, как самое малое.

это называется «статические тесты»

А происходят они не автоматически, да? Вот ты зануда.

Всё так. Я ж спросил выше, какие цели у твоих телодвижений. Или просто потому что модно.

у разраба одна цель - закоммитил/замерджил –> подождал немного –> получил результаты всех тестов на блюдечке с голубой каемочкой

да, я занудствую, потому что ручные тесты меня не интересуют, они все для меня либо автоматизированы на 99%, либо автоматические

В код продукта никто не лазиит со стороны тестирования.

статические тесты - это для разрабов в основном. Интегратору и системному тестировщику, конечно, до фени что кто-то там что-то криво закодировал или криво задокументировал

у разраба одна цель - закоммитил/замерджил –> подождал немного –> получил результаты всех тестов на блюдечке с голубой каемочкой

Как-то неправильно.

Результаты всех тестов должны быть до коммита, и только если все тесты проходят, то только тогда должна быть возможность мерджить…

Твоя контора в каменном веке

ну мерджить можно в тестовую ветку

ну это мне примерно было и так ясно. Следующий вопрос, что с этим делать:

1. самому пилить все автоматизации, благо кое какой хардвер доступен;

2. капать на мозг начальству. Но в связи с кризисом люди уходят, некому пайплайны настраивать и с разрабами говорить;

3. менять контору?

CD нет, слишком сложный деплой.

Есть CI с юнит-тестами от разрабов; QA отдел делает приемочные и нагрузочные тесты ещё, они вообще автоматизированы, но их запуск - нет, так что за CI это не считается наверное.

капать на мозг начальству.

В смысле, чтобы они давали тебе помощников для внедрения DevOps?

Но в связи с кризисом люди уходят, некому пайплайны настраивать и с разрабами говорить;

В смысле у вас процветает нищебродство?

На прошлой работе был полноценный CI/CD. На пуш запускались линтеры, тесты, смёржить нельзя было, пока все не пройдут успешно.

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

На текущей работе есть только кривой CI на Jenkins. Этот Jenkins делали рептилоиды-инопланетяне с руками из жопы. Как минимум, они были дальтониками, потому что выбор ими совершенно неочевидных цветов для успешных/сломавшихся билдов нельзя объяснить никакой другой причиной.

Да и вообще, я не понимаю логику авторов Jenkins. Явно инопланетяне под фентанилом писали, которые понятия не имели о человеческом UX.

Это ты про настройку дженкинса и какого-нибудь лейера между ним и гитом, типа геррита? Ну да, есть. В этом никто ничего не понимает правда. Ругается значит ошибка, вот и все.

В смысле у вас процветает нищебродство?

в точку!

У нас в паре нищебродских проектов именно jenkins и gerrit, ну и сборка, разумеется, в docker. Сладкая тройка.

Если это упростит твою работу то пили сам все автоматизации.

Если не упростит, то не пили.

Все практики созданы для того чтобы упростить создания продуктов, а не для карго культа.

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

Все едет в продакшен через CI/CD.

Breaking changes деплоим через Blue/Green ручками.

У нас прогоняется порядка 6000 тестов. Многие из них тестируют сразу кучу вещей, так что можно дать оценку, положим, в 20 000 тестов.

Каждый коммит всё это пробегает и только если оно всё зеленое, можно мержить в мастер.

Мастер считаем стабильным, никаких дополнительных тестов нет.

Тестирование вручную — вообще мало понятно, для чего оно на бекенде, но понимаю, зачем оно в гуе.

Все практики созданы для того чтобы упростить создания продуктов, а не для карго культа.

Я хочу верить этим словам, но не могу.

У нас через CI/CD идёт сборка и отправка на сервер проектов.
Работает на gitlab серваке собственном.

Собирается в docker контейнере. Если всё ok - идёт заливка на сервак.

На прошлой работе был полноценный CI/CD.

можно было прямо в GitLab ткнуть кнопочку, и оно всё автоматически раскатывалось

Это не «полноценный» CD. CD — это когда оно само деплоится в прод при мердже в мастер.

Исповедую, практикую.

Разработчики пишут юнит тесты и миграции, QA — функциональные, регресс и интеграционные тесты. Такой подход требует много людей и, желательно, кросс-функциональные команды, потому что нужно много телодвижений и коммуникации при запиливании новых фичей. Зато мантейнинг старый фичей считай бесплатный.