Гайд по DevOps для начинающих

Автор оригинала: Sameer S Paradkar
  • Перевод
В чем важность DevOps, что он означает для ИТ-специалистов, описание методов, фреймворков и инструментов.

image

Многое произошло с тех пор, как термин DevOps закрепился в IT-мире. С учетом того, что большая часть экосистемы имеет открытый исходный код, важно пересмотреть, почему это началось и что это значит для карьеры в IT.

Что такое DevOps


Хотя нет единого определения, я считаю, что DevOps — это технологическая структура, которая обеспечивает взаимодействие между командами разработчиков и операционными командами для более быстрого развертывания кода в производственных средах с возможностью повторения действий и автоматизации. Остаток статьи мы потратим на распаковку этого утверждения.

Слово «DevOps» является объединением слов «разработка» (development) и «операции» (operations). DevOps помогает увеличить скорость доставки приложений и услуг. Это позволяет организациям эффективно обслуживать своих клиентов и становиться более конкурентоспособными на рынке. Проще говоря, DevOps — это согласованность между разработкой и ИТ-операциями с более эффективным взаимодействием и сотрудничеством.

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

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

Вызовы для команды разработчиков


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

  • Конкурентный рынок создает большое давление для своевременной поставки продукта.
  • Они должны заботиться об управлении кодом, готовым к производству, и внедрении новых возможностей.
  • Цикл выпуска может быть длинным, поэтому команде разработчиков приходится делать несколько предположений перед внедрением приложений. В таком сценарии требуется больший запас времени для решения проблем, возникающих во время развертывания в производственной или тестовой среде.

Проблемы, с которыми сталкивается операционная группа


Операционные группы исторически ориентированы на стабильность и надежность ИТ-сервисов. Именно поэтому операционные команды занимаются поиском стабильности с помощью внесения изменений в ресурсы, технологии или подходы. К их задачам относятся:

  • Управление распределением ресурсов по мере роста спроса.
  • Обработка изменений в дизайне или настройках, необходимых для применения в производственной среде.
  • Диагностика и решение проблем, связанных с производством, после самостоятельного развертывания приложений.

Как DevOps решает проблемы разработки и операций


Вместо того, чтобы выкатывать большое количество функций приложения одновременно, компании пытаются выяснить, смогут ли они развернуть небольшое количество функций для своих клиентов с помощью серии итераций релизов. Такой подход имеет ряд преимуществ, таких как лучшее качество программного обеспечения, более быстрая обратная связь с клиентами и т.д. Это, в свою очередь, обеспечивает высокую степень удовлетворенности клиентов. Для достижения этих целей от компаний требуется:

  • Снизить процент отказов при выпуске новых релизов
  • Увеличить частоту развертывания
  • Достичь более быстрого среднего времени на восстановление в случае выхода нового релиза приложения.
  • Сократить время на исправления

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

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

  • Изолированность работы команд разработчиков и операторов
  • Тестирование и развертывание в виде отдельных фаз, выполняемых после проектирования и сборки и требующих больше времени, чем циклы сборки.
  • Чрезмерные времязатраты на тестирование, развертывание и проектирование вместо фокуса на создании основных бизнес-услуг
  • Ручное развертывание кода, приводящее к ошибкам в производстве
  • Разница в графиках работы групп по разработке и операциям, приводящая к дополнительным задержкам

image

Противостояние DevOps, Agile и традиционного IT


DevOps часто обсуждается в связи с другими ИТ-практиками, в частности, гибкой и водопадной ИТ-инфраструктурой.

Agile — это набор принципов, ценностей и методов производства программного обеспечения. Так, например, если у вас есть идея, которую вы хотите преобразовать в программное обеспечение, вы можете использовать принципы и ценности Agile. Но это программное обеспечение может работать только в среде разработки или тестирования. Вам нужен простой и безопасный способ быстро и с высокой повторяемостью переносить программное обеспечение в производственную среду, а путь лежит через инструменты и методы DevOps. Гибкая методология разработки программного обеспечения сосредоточена на процессах разработки, а DevOps отвечает за разработку и развертывание — самым безопасным и надежным способом.

Сравнение традиционной водопадной модели с DevOps – хороший способом понять преимущества, которые дает DevOps. В следующем примере предполагается, что приложение будет запущено через четыре недели, разработка завершена на 85%, приложение будет запущено, и процесс закупки серверов для отправки кода только что был начат.

Традиционные процессы Процессы в DevOps
После размещения заказа на новые серверы команда разработчиков работает над тестированием. Оперативная группа работает над обширной документацией, необходимой на предприятиях для развертывания инфраструктуры. После размещения заказа на новые серверы, команды разработчиков и операторов совместно работают над процессами и документооборотом для установки новых серверов. Это позволяет лучше понять требования к инфраструктуре.
Искажена информация о восстановлении после отказа, избыточности, расположении центров обработки данных и требованиях к хранилищам, так как отсутствуют входные данные от команды разработчиков, которая обладает глубокими знаниями в области применения. Подробная информация о преодолении отказа, избыточности, аварийном восстановлении, расположении центров данных и требованиях к хранилищам известна и корректна благодаря вкладу команды разработчиков.
Оперативная группа не имеет представления о прогрессе команды разработчиков. Также она разрабатывает план мониторинга на основе собственных представлений.
Оперативная группа полностью осведомлена о прогрессе, достигнутом командой разработчиков. Она также взаимодействует с командой разработчиков, и они совместно разрабатывают план мониторинга, который удовлетворяет IT и потребности бизнеса. Они также используют инструменты мониторинга производительности приложений (APM).
Нагрузочный тест, проводимый перед запуском приложения, приводит к сбою приложения, что задерживает его запуск. Нагрузочный тест, проводимый перед запуском приложения, приводит к снижению производительности. Команда разработчиков быстро устраняет узкие места, и приложение запускается вовремя.


Жизненный цикл DevOps


DevOps подразумевает принятие определенных общепринятых практик.

Непрерывное планирование


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

Совместное развитие


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

Непрерывное тестирование


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

Непрерывные выпуск и развертывание


Эти методики привносят за собой одну из основных практик: непрерывные выпуск и развертывание. Это обеспечивают непрерывный конвейер, который автоматизирует ключевые процессы. Он сокращает количество ручных операций, время ожидания ресурсов и объем переделок, позволяя осуществлять развертывание по нажатию кнопки, что обеспечивает большее количество релизов, снижение количества ошибок и полную прозрачность.

Автоматизация играет ключевую роль в обеспечении стабильного и надежного выпуска программного обеспечения. Одна из важнейших задач заключается в том, чтобы взять на вооружение ручные процессы, такие как сборка, регрессия, развертывание и создание инфраструктуры, и автоматизировать их. Для этого требуется контроль версии исходного кода; сценарии тестирования и развертывания; данные об инфраструктуре и конфигурации приложений; а также библиотеки и пакеты, от которых зависит приложение. Еще одним важным фактором является возможность запрашивать состояние всех сред.

Непрерывный мониторинг


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

Постоянная обратная связь и оптимизация


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

image

Преимущества DevOps


DevOps может способствовать созданию среды, в которой разработчики и операторы работают как одна команда для достижения общих целей. Важной вехой в этом процессе является внедрение непрерывной интеграции и непрерывной доставки (CI/CD). Эти методики позволят командам быстрее выводить программное обеспечение на рынок с меньшим количеством ошибок.

Важными преимуществами DevOps являются:

  • Предсказуемость: DevOps предлагает значительно более низкую частоту отказов при выпуске новых релизов.
  • Поддерживаемость: DevOps обеспечивает легкое восстановление в случае сбоев в новом релизе или отключения приложения.
  • Воспроизводимость: Система контроля версий сборки или кода позволяет восстанавливать более ранние версии по мере необходимости.
  • Более высокое качество: Решение проблем с инфраструктурой улучшает качество разработки приложений.
  • Время выхода на рынок: Оптимизация доставки программного обеспечения сокращает время выхода на рынок на 50%.
  • Снижение риска: Обеспечение безопасности в жизненном цикле программного обеспечения снижает количество дефектов на протяжении всего жизненного цикла.
  • Экономическая эффективность: Стремление к экономической эффективности при разработке программного обеспечения нравится высшему руководству.
  • Устойчивость: Программная система более стабильна, безопасна, а изменения можно проверять.
  • Более крупная кодовая база разбивается на управляемые части: DevOps основан на гибких методах разработки, которые позволяют разбивать большую кодовую базу на более мелкие и управляемые части.

Принципы DevOps


Принятие DevOps породило несколько принципов, которые эволюционировали (и продолжают эволюционировать). Большинство поставщиков решений разработали свои собственные модификации различных методик. Все эти принципы основаны на целостном подходе к DevOps, и организации любого размера могут использовать их.

Разрабатывайте и тестируйте в среде, похожей на производственную


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

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

Развертывание с воспроизводимыми, надежными процессами


Этот принцип позволяет командам разработчиков и операторов поддерживать гибкие процессы разработки программного обеспечения на протяжении всего жизненного цикла. Автоматизация имеет решающее значение для создания итеративных, надежных и воспроизводимых процессов. Следовательно, организация должна создать конвейер доставки, обеспечивающий непрерывное автоматизированное развертывание и тестирование. Частое развертывание также позволяет командам тестировать процессы развертывания, тем самым снижая риск сбоев развертывания во время реальных релизов.

Мониторинг и проверка качества работы


Организации хороши в мониторинге приложений на производстве, потому что у них есть инструменты, которые фиксируют показатели и ключевые показатели эффективности (KPI) в режиме реального времени. Этот принцип переносит мониторинг на ранние стадии жизненного цикла, гарантируя, что автоматизированное тестирование отслеживает функциональные и нефункциональные атрибуты приложения на ранних стадиях процесса. Всякий раз, когда приложение тестируется и развертывается, качественные показатели должны быть изучены и проанализированы. Инструменты мониторинга обеспечивают раннее оповещение о проблемах, связанных с эксплуатацией и качеством, которые могут возникнуть в процессе производства. Эти показатели должны быть собраны в формате, доступном и понятном всем заинтересованным сторонам.

Усовершенствование циклов обратной связи


Одна из целей процессов DevOps заключается в том, чтобы дать возможность организациям быстрее реагировать и вносить изменения. При поставке программного обеспечения эта цель требует, чтобы организация получала обратную связь на ранней стадии, а затем быстро училась на каждом предпринятом действии. Этот принцип требует от организаций создавать каналы коммуникации, которые позволяют заинтересованным сторонам получать доступ и взаимодействовать по принципу обратной связи. Разработка может осуществляться путем корректировки своих проектных планов или приоритетов. Производство может действовать путем улучшения производственной среды.

Dev


  • Планирование: Kanboard, Wekan и другие альтернативы Trello; GitLab, Tuleap, Redmine и другие альтернативы JIRA; Mattermost, Roit.im, IRC и другие альтернативы Slack.
  • Написание кода: Git, Gerrit, Bugzilla; Jenkins и другие инструменты с открытым исходным кодом для CI/CD
  • Сборка: Apache Maven, Gradle, Apache Ant, Packer
  • Тесты: JUnit, Cucumber, Selenium, Apache JMeter


Ops


  • Выпуск, развертывание, операции: Kubernetes, Nomad, Jenkins, Zuul, Spinnaker, Ansible, Apache ZooKeeper, etcd, Netflix Archaius, Terraform
  • Мониторинг: Grafana, Prometheus, Nagios, InfluxDB, Fluentd, и другие, покрытые в этом руководстве

(* Инструменты для операций были пронумерованы в порядке применения операционными командами, но их инструментарий перекрывается стадиями жизненного цикла инструментами релиза и развертывания. Для удобства чтения нумерация была убрана.)

В заключение


DevOps — это все более популярная методология, целью которой является объединение разработчиков и операторов в единое целое. Она уникальна, отличается от традиционных IT-операций и дополняет Agile (но не является столь же гибкой).

image

Узнайте подробности, как получить востребованную профессию с нуля или Level Up по навыкам и зарплате, пройдя платные онлайн-курсы SkillFactory:



Полезное


SkillFactory
Школа Computer Science. Скидка 10% по коду HABR

Комментарии 21

    0
    технологическая структура

    надо больше терминов
      +3
      Водная вода.

      Вот предположим у меня есть некое приложение, разработка и выкатка на бой которого не автоматизированы (какой-нибудь битрикс, например, чтобы не ходить далеко).
      Тестовая среда (если есть) не идентичная боевой, т.к. находится даже на другой площадке (часто на локальной машине разработчика).
      Тестирование зачастую не автоматизировано, т.к. большая часть изменений «визуальные» (поиграйте со шрифтами и вот это всё).
      Даже предположим, есть система контроля версий (ну, в смысле все изменения на бою коммитятся в GIT).
      Но нет автоматизированной публикации, т.к. она связана не только с файлами, но и с БД. Да и правки могут быть (и в файлах и в БД) как от разработчика, так и от каких-то контент-менеджеров, которые новости фигачат прямо на бой.

      Вот как в этом всём видится DevOps?

      Можно сколько угодно красивых терминов ввести, но вот описанный выше кошмар я не представляю как автоматизировать в красивую историю. А если всё это работает, то никто в здравом уме не выкинет его и не начнёт пилить с нуля на «правильном» фреймворке.

      P.S. я не противник DevOps, я просто не понимаю что всё эта история значит конкретно (не говоря уже про то как в этому счастью прийти). А подобные статьи только водную воду добавляют…
        –1
        как вижу это я, если что-то похожее на битрикс можно поставить не только лишь на проде, то делаем следующим образом, ставим копию на проде, копию на тестовом сервере, и копию на рабочем компьютере. в Git'е ветка master пушится в прод, test пушится в тестовый сервер, в dev сливается с других веток. кем то смотрится, тестируется, если есть тесты, мержится в test, соответственно если в github то через Actions через какой нибудь rsync заливается на тестовый сервер, на дашборд куда нибудь сообщается, что тестовый сервер готов к проверке. тестируется, если все нормально, мержится в мастер и тоже самое в отправляется прод. вот уже есть какой никакой pipeline, в него потихоньку встраивается тестирование. выделяются люди, если над проектом работает много людей, ответственных за проект, типа архитекторы. Они занимаются мержем из dev в test и master соответственно. У них свои метрики, KPI если хотите, они ответственны за код который выкатывают в прод. Если мало человек в проекте, ну как то настроить, чтобы друг друга проверяли, выделяли время и искали друг у друга ошибки. Т.е. должен быть кто-то со стороны, кто может сказать, что вот это у тебя завалит скорее всего вот то-то и то-то. Ну или тесты прогонять.
        Сумбурно, но как то так я думаю.
          0
          Поставить на 3 серверах веб приложение не проблема.
          Поставить на всех 3 серверах GIT и настроить на общий remote тоже не проблема, как я описал выше.
          Проблема в том, что такого рода приложения очень сильно завязаны на изменение контента. И контент часто меняется не только в БД, но и в файлах. И часто в одном и том же файле часть изменений вносится редактором контента, а часть разработчиком. Так что GIT становится только средством «слежения» за изменениями, но не средством их наката.
          А ещё более-менее серьёзные изменения это не только файлы, но и изменения в БД, которые принято выполнять инструментами самого битрикса, т.е. админки. Нет скриптов для наката/отката таких правок.

          Да, их можно для каждой конкретной задачи написать. Но это лишние трудозатраты и риск ошибки. А тут нам вроде бы автоматизацию обещают, да ещё повышение надёжности…

          Так что можно называть всё это «пайплайн», «девопс», как угодно ещё. Суть остаётся прежней — нет описания ЧТО конкретно надо делать. И зачем.
          Увы, ваш комментарий не ответил на на один из моих вопросов.

          P.S. А это я ещё не говорю про 1С. Там у ребят, как мне кажется, ещё веселее…
            0
            Суть остаётся прежней — нет описания ЧТО конкретно надо делать. И зачем.


            Я тут ниже упомянул «технологов».
            Их работа заключалась, в частности, в том, что бы составлять карты технологического процесса -т.е. расписывать процесс выполнения всех действий, разбитый на элементарные операции.
            Так, что бы каждый, кто умеет читать — понимал, какие действия и в какой последовательности необходимо выполнять (и какой инструмент при этом использовать)
            Причем было неважно — серийное это производство или нет — если процесс был достаточно сложным — карты заполняли и для единичного производства.

            Но это лишние трудозатраты и риск ошибки.


            Это далеко не лишние трудозатраты.
              0
              ну, если хотеть начитать двигаться к правильным процессам, то так или иначе надо что-то менять. Менять плохие практики на хорошие.
              С базой данных так или иначе деплой через Git не сделаешь. Но и меняются данные, так чтобы ничего не сломалось. Т.е. эволюционно. Наращивая функционал. Т.е. база данных правится, и потом уже накатывается код, который обрабатывает новый функционал. Так вот, изменения в коде заворачивать на Git, да не так удобно, как заливать через FTP. Ну можно сократить до 2 серверов, все равно же не на продакте сразу все изменения делаете.
              Потом, на сервера git ставить не надо. github actions или gitlab pipeline это такие штуки, которые видят что, что-то запушилось в master или другую ветку, это как настроить, и поднимают docker, в нем если надо проверяют, делают какую то рутину, и заливают на сервер данные как это сделали бы Вы сами, хоть через FTP хоть через rsync. Как Вам уже нравится.
              Но да, Git в первую очередь тут является средством слежения за изменениями. Вы правы. Потому что если на проекте работаешь не один, где то кто-то внес какие то изменения, не отразил в документации или еще что, и все. А тут мы можем посмотреть, процесс изменения зависимых файлов. как и что в них правилось.
              И еще, меняться очень сложно, меняться очень больно. Но если Вы понимаете что живете и работаете в кошмаре, что что-то не так, надо что-то делать. Либо не делать. До какого нибудь глобального факапа. Если все всех устраивает, то и менять ничего не надо, работает не трогай. Но если все таки кажется что, что-то не так, то маленькими шажками, надо двигаться к свету.
                0
                Извините, ерунда какая-то. Да, я понимаю, вы за всё хорошее и против всего плохого, я тоже.
                НО.
                Я описал вполне конкретную ситуацию (и она не уникальна, для других продуктов тоже бывает схожая), когда красивыми словами не обойтись.
                Нужна конкретика.
                И эта конкретика должна как-то преодолевать ограничения заложенные продуктом.
                Который, на секундочку, работает и приносит пользу. А перелом этих ограничений будет стоить Заказчику увеличения трудозатрат. В разы. Просто потому всё ВСЁ придётся писать с нуля самим.
                А зачем? Какую задачу ваши «хорошие» практики решают, которую не решают описанные мною «плохие»?

                Поверьте, мне тоже нравится сделать git push на локальной машине в github, а потом смотреть как на heroku пересобирается мой python пэт-проект. Зависимости там обновляет и всё такое. Но это совершенно разный масштаб бедствия и тут я сразу заложил эту возможность.

                А вы всё талдычите «пайплайн», «докер», «делает рутину»… Слов красивых много, конкретики мало.
                  0
                  если честно ерунда какая то, я посмотрел Ваши публикации, примерно в общем описал точно такой же процесс из Вашей же публикации «Как я перестал беспокоиться и стал коммитить в GIT на большом 1С-Битрикс проекте» а Вы сейчас на меня злитесь, что я возможно Вам не даю четкие шаги, как все надо делать, а талдычу красивыми словами. В каком месте сломалась логика нашей беседы?
                    0
                    Логика моих сообщений в том, что те практики, что я описал были внедрены на очень старом и довольно большом проекте с кучей костылей и правок ядра.
                    Этот процесс не претендовал тогда и не претендует сейчас на звание DevOps.
                    Этот процесс не автоматизирует накат полностью, в нём нет тестов (кроме как «глазками»). Это именно контроль целостности файлов и небольшая страховка от того чтобы при накате разработчик «не забыл» пару файлов (хотя тоже не факт что рабочая, т.к. накат обычно затрагивал несколько репозиториев).

                    Я тогда писал о том как на грёбаном битриксе хоть что-то подвести под git.

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

                    И повторюсь, это ещё не самая жесть. 1С, как мне помнится, ещё веселее.
                      +1
                      во :) теперь я Вашу попаболь понял. Просто на самом деле, нет единого какого то стандарта, есть общие принципы, а вариантов то много. Так же степень devops'а может быть разной, т.е. автоматизировать какой то процесс, или вообще все процессы. Это только методики и рекомендации, как правильно. А как использовать, что применять, все зависит от предметной области. Возможно то что Вы описали и нельзя нормально настроить, в силу специфических каких то причин.
                      Ну просто например создавать какой то относительно большой командой Java десктопное приложение, и скажем обычный сайтик, и т.д. это все разные процессы. Нельзя все под одну гребенку. Поэтому я и говорю, если чувствуете что что-то не то, меняйте, адаптируйте, автоматизируйте. Чтобы как можно меньше была зависимость от конкретного человека, как можно меньше ручного труда нужно было делать в процессе изменения сайта и т.п.
                        0
                        Вот в том и беда, что сколько я статей, методик и рекомендаций пока ни читаю, нигде нет конкретики (очень редко встречаются описания более-менее подробные с конфигами но, естественно, не под мои среды и приложения).
                        А на работе уже навис DevSecOps. там огромные простыни текста, которые тоже не содержат ничего полезного, как и эта статья. А он принудительно обязателен для всех.

                        А умные слова и вода, как из этой статьи… Они бесполезны.
                          0
                          ну смотрите, если у организации есть бюджет и потребность, лучше сходить на какие нибудь курсы по DevOps'у, во первых они шире откроют глаза на понимание проблемы, во вторых Вы сможете помучать преподавателей собственными проектами, т.е. как сделать конкретно на примере вот этого, и уже будете разбирать свой кейс, Вам дадут направление куда идти, что читать, куда копать. И может быть, по результату что нибудь да получится. из того что могу вспомнить, не сочтите только за рекламу :) это rebrain, у них сильные девопсы, они ведут бесплатные вебинары, где очень много полезного и я их стараюсь не пропускать. канал в телеграме можете посмотреть называется DevOps by REBRAIN. Там прилетают ссылки на вебинары. На вебинарах Вы сможете узнать уже о подробностях обучения. Можете в Otus посмотреть, тоже по девопсу, я там обучался на другом курсе, мне понравилось. Но обучение не гарантирует конечно что у Вас все получится. Есть еще один вариант, это платные консультации со специалистами в этой области. Посмотреть на тех же преподавателей из этих курсов, связаться с ними по почте, договориться, и проконкультироваться от и до как вариант.
                            0
                            Какой смысл идти на курсы по DevOps'у, если там будут повторять ту же воду, что в статьях, но за деньги?
                            Какие основания считать, что там будет не вода?
                              0
                              нет, гарантий я думаю тут никто не даст, просто может быть, если есть желание продвинуться в этой истории, то можно привести мысли и знания в порядок, и тогда в совокупности, у Вас появится какой то опыт, за ним и понимание как можно решить проблему именно в Вашем случае. Но по факту, может конечно статься так, что Вы зададите вопрос преподавателю, как сделать? Он посмотрит и скажет, тут ничего нельзя сделать.
            0
            Вода камень точит. В идеале должно совпадать и люди (видение) и выбранные технологии. В моей практике команды Dev и Ops начинали с чего-то малого, то есть пилили PoC на одном из окружений, стендов. Затем собирались вместе и на основе полученного опыта пилили шаблоны, скрипты автоматизации и тянули конвейер CI/CD дальше.
            0
            Что такое DevOps


            Раньше этот процесс назывался «внедрение», а инженеры, которые им занимались де-факто, носили обобщающее название «технологи».

            (КДПВ просто замечательная. Сохранил для себя)
              0
              Все правильно, но написано каким-то вымученным языком. Может, и сам DevOps такой же?
                0
                ИМХО это просто чтобы создать ореол элитарности и оправдать ту кучу бабла, которые они получают, хотя на самом деле обычные админы плотно работающие с разрабами и выполняющие все их прихоти.
                0
                «между командами разработчиков и операционными командами для более быстрого развертывания кода в производственных средах»


                Операционные команды это кто?
                Производственные среды это что?
                Вы на систему управления ядерными реакторами хотитие обновление 5 раз на дню накатывать? Остановите шарикм я сойду.

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


                Т.е превратить жизнь Юзеров в бесконечный кошмар.

                «Организации используют DevOps для достижения таких уровней производительности, которые еще несколько лет назад были немыслимы. Они выполняют десятки, сотни и даже тысячи развертываний в день, обеспечивая при этом надежность, стабильность и безопасность мирового класса»


                Я один подозреваю что что-то в этом не так? Что-то не здоровое?
                «Чрезмерные времязатраты на тестирование, развертывание и проектирование вместо фокуса на создании основных бизнес-услуг»


                Мне кажется я нашел ключевой принцип этого нового лохотрона. Нахрен тестирование. Юзер лучший тестер. А что бы он не возмущался убедить его что это теперь модно. В таком потоке фичь он скоро забудет что ему там реально было надо. И да, производственные среды это прсто конструктор катастроф.
                  0
                  В итоге девопс стал просто красивым названием для продвинутых админов, сколько бы там не кричали про философию и методологию
                    0

                    Девопс девопсу рознь в зависимости от потребностей заказчика (компании) и как-то описывать под общую структуру саму методологию сомнительная идея

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое