Комментарии 11
НЛО прилетело и опубликовало эту надпись здесь
(но зачем?)
Вообще же, предлагаемые инструменты на это не рассчитаны. Они предполагают, что вы уже собрали проект, и у вас есть готовый релиз.
Вообще же, предлагаемые инструменты на это не рассчитаны. Они предполагают, что вы уже собрали проект, и у вас есть готовый релиз.
Тогда это только Ops-часть от DevOps.
Это зависит от вашего понимание DevOps.
Нет. На таком основании можно сказать про любой термин, придумав под него новые значения.
DevOps имеет вполне очерченный смысл термина. Как минимум, могу поспорить на миллион долларов, в названии DevOps первые три буквы — Dev. Вам же это о чем-то говорит? :-)
DevOps имеет вполне очерченный смысл термина. Как минимум, могу поспорить на миллион долларов, в названии DevOps первые три буквы — Dev. Вам же это о чем-то говорит? :-)
DevOps имеет вполне очерченный смысл термина
Какой?
Как минимум, могу поспорить на миллион долларов, в названии DevOps первые три буквы — Dev. Вам же это о чем-то говорит?
Говорит. О том, что разработчики принимают участие в развертывании и поддержке. Если инструментарий позволяет разработчику выкатить продукт, и возвращает фидбек напрямую разработчику же — это и есть DevOps.
Вы знаете, я каждый день прихожу на работу и вижу десятки «девопсов», которые сидят и автоматизируют бардак разработчиков. Они называют все свои джобы с префиксом CI — таким образом это становится continuous integration.
Они ничего общего с девопсом не имеют.
Тем временем мне на почту сыпятся десятки статей в неделю с названиями «10 лучших инструментов DevOps» или «таблица DevOps инструментов».
Люди, которые это пишут, равно как наши «девопсы» в компании свято убеждены — если ты что-то заавтоматизировал, то ты сделал DevOps.
Мои поздравления, автоматизация не имеет вообще ничего общего с DevOps, равно как все эти приколюхи типа Jenkins или Docker, от которых в глазах рябит.
Давайте мы оставим buzz-word DevOps и вернемся к истокам этого значения?
DevOps, тот самый настоящий, который был изобретен бельгийцами 9 лет назад, — это решение проблемы взаимной ответственности в команде. Ключевое слово — взаимной. Если для этого нужна автоматизация — пожалуйста. Если для автоматизации нужен Jenkins — пожалуйста. Но это не во главе угла. Это даже не 10% работы по этой части.
Основная работа состоит в том, чтобы управлять взаимодействием.
1. Чтобы зависимости, которые ставились у разработчика, попадали в прод в обязательном порядке (будь то сделано через uDeploy или руками на листочке записали — неважно).
2. Чтобы код тестировался на всех стадиях в условиях приближенных к продовским и на чистых серверах, а не после многочисленных настроек разработчиком.
3. Чтобы разработчики могли планировать green/blue-деплоймент в проде на базах (это экстремально тяжелая задача, потому что две версии не работают с одной схемой)
4. Чтобы менеджеры могли планировать время траблшутинга проблемы (да да, это существует — Visible Ops)
И вот вы пишете, что кусок процесса на стадии Dev не рассматривается, потому что:
Ага, собрали со своими депенденси, не пополнив список в pom.xml/requirements.txt/package.json [нужно подчеркнуть]. Со своими скриптами, которые никто не запустит в проде. И так далее.
Но да, разрабы получат «фидбек».
Конечно получат. А если Ops знают, где они живут, они и не только фидбек получат. Но когда им надоест получать, они придут к DevOps культуре, где фидбэков нет, потому что самим себе фидбэки не пишут.
Выдыхаю…
Они ничего общего с девопсом не имеют.
Тем временем мне на почту сыпятся десятки статей в неделю с названиями «10 лучших инструментов DevOps» или «таблица DevOps инструментов».
Люди, которые это пишут, равно как наши «девопсы» в компании свято убеждены — если ты что-то заавтоматизировал, то ты сделал DevOps.
Мои поздравления, автоматизация не имеет вообще ничего общего с DevOps, равно как все эти приколюхи типа Jenkins или Docker, от которых в глазах рябит.
Давайте мы оставим buzz-word DevOps и вернемся к истокам этого значения?
DevOps, тот самый настоящий, который был изобретен бельгийцами 9 лет назад, — это решение проблемы взаимной ответственности в команде. Ключевое слово — взаимной. Если для этого нужна автоматизация — пожалуйста. Если для автоматизации нужен Jenkins — пожалуйста. Но это не во главе угла. Это даже не 10% работы по этой части.
Основная работа состоит в том, чтобы управлять взаимодействием.
1. Чтобы зависимости, которые ставились у разработчика, попадали в прод в обязательном порядке (будь то сделано через uDeploy или руками на листочке записали — неважно).
2. Чтобы код тестировался на всех стадиях в условиях приближенных к продовским и на чистых серверах, а не после многочисленных настроек разработчиком.
3. Чтобы разработчики могли планировать green/blue-деплоймент в проде на базах (это экстремально тяжелая задача, потому что две версии не работают с одной схемой)
4. Чтобы менеджеры могли планировать время траблшутинга проблемы (да да, это существует — Visible Ops)
И вот вы пишете, что кусок процесса на стадии Dev не рассматривается, потому что:
Они предполагают, что вы уже собрали проект, и у вас есть готовый релиз.
Ага, собрали со своими депенденси, не пополнив список в pom.xml/requirements.txt/package.json [нужно подчеркнуть]. Со своими скриптами, которые никто не запустит в проде. И так далее.
Но да, разрабы получат «фидбек».
Конечно получат. А если Ops знают, где они живут, они и не только фидбек получат. Но когда им надоест получать, они придут к DevOps культуре, где фидбэков нет, потому что самим себе фидбэки не пишут.
Выдыхаю…
Я дам вам один пример, что такое реальный DevOps.
Когда я жил в России, то работал в Люксофте. У нас была база данных для приложения управления пожарными машинами в Москве. А наши разработчики писали это приложение. Я подумал, что было бы неплохо тестировать на базе продакшена. Поэтому при каждой сборке кода и деплое, скачивался бэкап прода за прошлый день и ставился на тестовое окружение.
Таким образом убил двух зайцев:
1. Каждый день тестировался вчерашний бэкап
2. Новый код работал с реальной базой в ее современном состоянии.
Вот это называется DevOps. Потому что были созданы условия, что накосячить невозможно. Накосячил в начале цепочки и то, что случится в конце случается сразу же в начале.
Когда я жил в России, то работал в Люксофте. У нас была база данных для приложения управления пожарными машинами в Москве. А наши разработчики писали это приложение. Я подумал, что было бы неплохо тестировать на базе продакшена. Поэтому при каждой сборке кода и деплое, скачивался бэкап прода за прошлый день и ставился на тестовое окружение.
Таким образом убил двух зайцев:
1. Каждый день тестировался вчерашний бэкап
2. Новый код работал с реальной базой в ее современном состоянии.
Вот это называется DevOps. Потому что были созданы условия, что накосячить невозможно. Накосячил в начале цепочки и то, что случится в конце случается сразу же в начале.
Релиз манагер выглядит неплохо но это он только так выглядит. Пока у него под капотом лежит Xaml, как и в tfs, а это такой один сплошной огромный геморрой. Может RM 2015 тоже будет без Xaml кто знает.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
DevOps tools от Microsoft