Вопросы о DevOps: автоматизация, деплой и команда QA

пусть девелоперы сами тестируют то что написали

+1

: +1

+1

в мастер

а куда ж еще

1 на команду

😆

толсто

На одной из собесов спрашивали, сколько сейчас у нас, ну я сказал как есть "четверо qa и 5 девелоперов". Офигение собеседника на том конце было слышно даже по телефону

В прошлой команде было типа 2 qa на четырёх девелоперов

Fullstack dev(ops) - самая востребованная в Германии специальность

А я и не знал, что для обычной методы как "Continuous Integration" существует отдельная профессия - devops.

Это билд инженер

Т.е. devops это типа админ, который следит за билдом, делает резервные копии и т.д.?

Он код пишет вместе с остальной командой

Т.е. вроде как 50/50, да?

Да

экономика должны быть экономной, а QA вообще не нужно

Почему на команду? Один на всю контору!

Ну и как он будет весь код знать

Полуадмин-полупрогер

там и зп у девопса пятизначная

да, чел там бывает по несколько дней не спит

Вот так оно обычно и бывает

встречал максимум 1го на 3-4 команды

Не повезло..

а то и вовсе пара на компанию

при чем компания со штатом 200 программеров и туева хуча проектов

херассе один на команду

не жирновато ли

Кстати, а сколько у вас QA на девелоперов?

Так девопс ето админ которий умеет кодить, не?

Не

Это программист, который умеет админить

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

Зависит от размеров команды и структуры

😂

Господи, ушел в отпуск, зашел в мюнхенский чат, а тут это все - терраформ, деплой, авс, девопс... Олег, начни с книги Continuous Delivery и делай как тебе удобней. Важны не инструменты, а концепции

Так поэтому я про концепции и спрашиваю, не?

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

ну так эту картинку же надо как-то понять) Понятно, что можно накостылить велосипедов и пройти по граблям самому, но если есть state-of-the-art решение данной проблемы - то наверное лучше сразу его попробовать применить?

я спросил - получил ответ - что подход норм, так и делают. Также на SO в паре ответов то же самое нашел. Значит пойду пробовать)

главное прод не урони )

пфф))))

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

потому что хочется меньше разгребать ситуации, когда локлаьно работает, а на проде нет

значит придется штудировать литературу и best practices

и хаусорднунг

да, что то сегодня и правда какой то вечер devops pipeline aufs Isarufer

>копируешь что-то в wwwroot где то на сервере с Apache, потом запускаешь chown

Забыл еще перед этим "25 минут усиленно вспоминаешь что же там с правами было и что надо дописать в конфиг" :)

ну это если к тебе раз в год приходят ребята из дев-тимы и просят "задеплой", и ты лезешь в гит, копируешь что-то в wwwroot где то на сервере с Apache, потом запускаешь chown, apachectl graceful и это занимает у тебя 5 минут, то на автоматизацию можно потратить25 минут. А вот если они приходят каждый день... то все меняется.

я же сказал, для devops отдела конторы это не опция

Devops отдел это не опция

я имел ввиду, что деплоить баш скриптами что то большое и серьезное - не решение для современного devops процесса:)

Ты их пойди найди ещё. Я за всю карьеру только двоих годных встречал

Может троих максимум

Большие команды обычно не эффективны

Кого их, не нужно создавать девонской отделы с леворадикальной инженерами

насколько я понимаю, в идеале DevOps - это "образ мышления" что ли, а не инженер на команду/контору. И некоторые разработчики с более сильным operations background вовлечены в этот процесс чуть больше

для моего прожекта то, что я написал - это целиком ВЕСЬ деплой. Все. Какие еще кусочки? Ну там какой-нибудь докер композе даун-ап может быть, ну ок. Но идеологически это именно что full deploy pipeline в моем случае. И я бы сказал, что в мало-средних проектах точно также все. Заменяй копирование на отправку в облако, mysql на более умный апдейт, но это *идеологически* полный деплой

Да

а уж зовет ли функция скрипт на баше или выполняет ямл построчно - детали

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

это как сравнивать что лучше python или assembler

грубо говоря, высокоуровнево любой деплой это же функция
deploy(source, to, config)
откуда деплоить (ветка), куда (файло\контейнер\облако), опции (параметры коннекта к базе там или типа того). Ну да, естественно, с поправками на многосерверные и супер-облачные конфигурации, но это другой мир какой-то

deploy(source, to, config) ну да, но вот как этим управлять, со сборкой, репозиториями, откатами, тестами, несколькими средами. Как обеспечить атомарность операций внутри пайплайна на баше? Наверное равносильно написанию гитлаба на баше)

>реюзабилити этой штуки 0 из 10
тоже не понял. Вот хоть сейчас бери этот скрипт и в любой другой проект кидай - ничего проектозависимого же.
можно пример\ссылку на "реюзабилити 10 из 10" или типа того? Собственно, можно же декомпозировать все это, миграции - одна библиотека, перелив проекта - отдельный скрипт\функция, но суть-то не меняется

Конкретно для твоей задачи сделать баш проще, но вот реюзабилити этой штуки 0 из 10. Т.е. это не подход опс отдела никак

Мой изначальный вопрос - насколько идеологически такой "деплой пайплайн" является правильным?