Comments 11
10 главных сложностей на пути к адаптации DevOps
заменяем DevOps на что угодно и получаем название очередного тренинга личностной эффективности =(
гы-гы. Если в тексте заменить Dev-Ops на любую методологию или технологию, то можно даже не менять текст.
Для примера:
Сложности и решения
Как же выглядит весь список главных сложностей на пути AGILE/TDD/к вселенскому благоденствию и что поможет в их решении?
1. Отсутствие культуры
Компаниям необходимо сфокусироваться на построении культуры взаимодействиями с общими (разделяемыми всеми участниками) целями. Важно также находить сотрудников, которые могут возглавлять отдел по внедрению AGILE/TDD/вселенского благоденствия внутри организации.
2. Автоматизация тестов
Многие компании отбрасывают автоматизацию тестирования, сосредотачиваясь на процессах CI/CD. Однако непрерывное тестирование — ключ к успеху в AGILE/TDD/вселенском благоденствии. С самого начала надо учитывать и вопросы безопасности.
3. Устаревшие системы
Учёт устаревшей инфраструктуры и приложений должен стать неотъемлемой частью ваших планов по внедрению AGILE/TDD/вселенского благоденствия. Установка нового оборудования или софта и их одновременное сосуществование с более старыми системами — это всегда трудно.
Для примера:
Сложности и решения
Как же выглядит весь список главных сложностей на пути AGILE/TDD/к вселенскому благоденствию и что поможет в их решении?
1. Отсутствие культуры
Компаниям необходимо сфокусироваться на построении культуры взаимодействиями с общими (разделяемыми всеми участниками) целями. Важно также находить сотрудников, которые могут возглавлять отдел по внедрению AGILE/TDD/вселенского благоденствия внутри организации.
2. Автоматизация тестов
Многие компании отбрасывают автоматизацию тестирования, сосредотачиваясь на процессах CI/CD. Однако непрерывное тестирование — ключ к успеху в AGILE/TDD/вселенском благоденствии. С самого начала надо учитывать и вопросы безопасности.
3. Устаревшие системы
Учёт устаревшей инфраструктуры и приложений должен стать неотъемлемой частью ваших планов по внедрению AGILE/TDD/вселенского благоденствия. Установка нового оборудования или софта и их одновременное сосуществование с более старыми системами — это всегда трудно.
5. Отсутствие плана по DevOps
Создайте чёткий план, включающий в себя этапы, ответственных и конкретные результаты..
Супер. Обожаю планы по вещам, которые не известны.
План научных открытый на 2017 год.
…
Менеджерам по научным открытиям обеспечить неуконснительное исполнение плана в соответствии с утверждённым графиком. Отвественным за научный прорыв назначить shurup.
Создайте чёткий план, включающий в себя этапы, ответственных и конкретные результаты..
Супер. Обожаю планы по вещам, которые не известны.
План научных открытый на 2017 год.
…
Менеджерам по научным открытиям обеспечить неуконснительное исполнение плана в соответствии с утверждённым графиком. Отвественным за научный прорыв назначить shurup.
«вещам, которые не известны» — а как вы собрались внедрять что-то, что вам неизвестно, и, главное, зачем вообще это делать?
Попробовав их! Откуда я знаю, что свежий модный молодёжный aptly лучше, чем старый олдфаговый и работающий reprepro? Попробовал, потом решил, годно оно или нет.
Всё современное IT построено на том, что пробуют внедриться вещи, которые не известно, хорошо или нет. Те, кто так не делают, сидят на виндосапе ровно и не дёргаются, те, кто делают — либо имеют проблемы (потраченные зря ресурсы), либо получают немалый прирост к эффективности.
Всё современное IT построено на том, что пробуют внедриться вещи, которые не известно, хорошо или нет. Те, кто так не делают, сидят на виндосапе ровно и не дёргаются, те, кто делают — либо имеют проблемы (потраченные зря ресурсы), либо получают немалый прирост к эффективности.
Я бы не стал сравнивать такую комплексную вещь, как DevOps, с такими частностями, как reprepro… Но ключевой момент здесь в другом: в статье/опросе речь скорее о тех, кто уже решился на сабж всерьёз, а не просто посмотреть-попробовать. Чтобы попробовать (а в том или ином виде это сделано) — всё описанное не нужно (потребуется на следующем этапе и некоторое понимание тогда уже быть должно).
Жалко что в опросе нет пункта — «Нет желания внедрять DevOps» — думаю это будет один из самых популярных ответов.
DevOps — это карго-культ. Я не говорю что он плох, но говорю о том что его нужно применять выборочно и осознано, а не из-за того что это модно и круто. Тоже могу сказать про автоматизированное тестирование и TDD. Если вы пишите API или сервисы и у вас до сих пор нет Unit-test-ов — мне вас жалко, но если у вас проект-монолит, которому уже 5-10 лет, то 100% покрытия не получится, да и оно не нужно.
На своём примере могу сказать, что работая 8 лет в различных компаниях (по большей части крупных и уважаемых) юнит тесты использовал очень редко т.к. либо за них не был готов платить заказчик, либо невозможно было прикрутить к существующему проекту. То же самое могу сказать про DevOps — если есть выгода для бизнеса — внедряем. Если нет, то нет (он отлично заменяется регламентами и планированием).
DevOps — это карго-культ. Я не говорю что он плох, но говорю о том что его нужно применять выборочно и осознано, а не из-за того что это модно и круто. Тоже могу сказать про автоматизированное тестирование и TDD. Если вы пишите API или сервисы и у вас до сих пор нет Unit-test-ов — мне вас жалко, но если у вас проект-монолит, которому уже 5-10 лет, то 100% покрытия не получится, да и оно не нужно.
На своём примере могу сказать, что работая 8 лет в различных компаниях (по большей части крупных и уважаемых) юнит тесты использовал очень редко т.к. либо за них не был готов платить заказчик, либо невозможно было прикрутить к существующему проекту. То же самое могу сказать про DevOps — если есть выгода для бизнеса — внедряем. Если нет, то нет (он отлично заменяется регламентами и планированием).
UFO just landed and posted this here
Хороший опрос, ставлю класс.
Sign up to leave a comment.
10 главных сложностей на пути к адаптации DevOps