История изменений
Исправление slackwarrior, (текущая версия) :
возможность максимально гибкого ограничения доступа к коду и инфраструктуре
Чаще это выливается в синдром вахтера у людей не в теме, но с админкой, и искуственные ограничения для девелоперов, когда «девопс общего назначения» имеет все права, но не понимает целевую систему и притаскивает замшелое гитфлоу 2010 года, про которое прочитал вчера на хабре, за которое автору пытались предъявлять что оно не масштабируется, а он их послал «думать своей головой»... Но поздно — уже по хабрам и атлассианам разнесли, так что первая страница выдачи гугла выдается за священное писание бестпрактисов :)
точка разделения труда разработчика и Dev/SysOps
искусственное разделение в котором девопс чаще не нужен или мешает, если не обладает нужными познаниями в целевой платформе, для которых надо сдать курсы админа этой платформы :)
сырая технология
Идеям этим лет 20. Сырая конкретная реализация :)
затраты на конфигурацию окружения
не больше чем в любой системе к которой полагается платно сертифицированный амин :)
больше точек отказа
точка отказа чаще — твой интернет или настройка SSO, когда захотели не штатную для платформы, а внешнее «командование клитором» через какой-нибудь Azure AD :)
точки отказа более централизованны
Инстансы в облаке порой чаще децентрализованы («живые миграции», сегодня здесь, завтра там). Вот мода на вебморды для гита скорее искусственную эту централизацию навязывает. Копии репозитория у девелоперов технически вообще равноправны. Девелоперам, которые понимают что делают, эта вебшляпа-комбаен «для прозрачности» не нужна. Девопсам и заказчикам может быть.
сложнее в развёртывании
А тебе ничего и не приходится «развертывать-развертывать». По шаблону инстансы накатываются и «наборы изменений» туда-сюда между ними. Что у платформы под капотом вообще можно не знать, т.к. повлиять ты на это не сможешь :) И простынка на ямле для пайплайна и всего-всего вряд ли сложнее ручного накатывания через ssh и поднимания CI/CD из россыпи отдельных молотков, склеенных наколенной скриптотой с конфигами на разных языках разметки.
Исходная версия slackwarrior, :
возможность максимально гибкого ограничения доступа к коду и инфраструктуре
Чаще это выливается в синдром вахтера у людей не в теме, но с админкой, и искуственные ограничения для девелоперов, когда «девопс общего назначения» имеет все права, но не понимает целевую систему и притаскивает замшелое гитфлоу 2010 года, про которое автору пытались предъявлять что оно не масштабируется, а он их послал «думать своей головой» :)
точка разделения труда разработчика и Dev/SysOps
искусственное разделение в котором девопс чаще не нужен или мешает, если не обладает нужными познаниями в целевой платформе, для которых надо сдать курсы админа этой платформы :)
сырая технология
Идеям этим лет 20. Сырая конкретная реализация :)
затраты на конфигурацию окружения
не больше чем в любой системе к которой полагается платно сертифицированный амин :)
больше точек отказа
точка отказа чаще — твой интернет или настройка SSO, когда захотели не штатную для платформы, а внешнее «командование клитором» через какой-нибудь Azure AD :)
точки отказа более централизованны
Инстансы в облаке порой чаще децентрализованы («живые миграции», сегодня здесь, завтра там). Вот мода на вебморды для гита скорее искусственную эту централизацию навязывает. Копии репозитория у девелоперов технически вообще равноправны. Девелоперам, которые понимают что делают, эта вебшляпа-комбаен «для прозрачности» не нужна. Девопсам и заказчикам может быть.
сложнее в развёртывании
А тебе ничего и не приходится «развертывать-развертывать». По шаблону инстансы накатываются и «наборы изменений» туда-сюда между ними. Что у платформы под капотом вообще можно не знать, т.к. повлиять ты на это не сможешь :) И простынка на ямле для пайплайна и всего-всего вряд ли сложнее ручного накатывания через ssh и поднимания CI/CD из россыпи отдельных молотков, склеенных наколенной скриптотой с конфигами на разных языках разметки.