DevOps против SDLC: оптимизация цикла разработки программного обеспечения

DevOps против SDLC: оптимизация цикла разработки программного обеспечения

13 декабря 2022 г.

Если вы используете традиционный жизненный цикл разработки программного обеспечения (SDLC), у вас могут возникнуть вопросы о том, какое место занимает DevOps. Могут ли они существовать вместе или слишком много конфликтов?

В этом посте рассматриваются различия между двумя подходами.

Что такое SDLC?

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

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

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

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

Для чего был создан SDLC?

Чтобы понять мотивацию SDLC, вам нужно отправиться в прошлое. Наша история поставки программного обеспечения следует за эволюцией процессов разработки с 1950 года. Мы обнаружили, что технологии сыграли важную роль в изменении того, что необходимо. Точно так же, как ученые ограничены оборудованием, доступным для их экспериментов, ранние разработчики были ограничены дефицитом машин, которые были дорогими в эксплуатации, требовали длительного времени компиляции и ограниченных инструментов для редактирования кода.

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

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

* 1989 - Тим Бернерс-Ли изобрел Всемирную паутину * 1997 — запуск Google * 2008 – появилось переполнение стека

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

SDLC решил 2 типа проблем:

  1. Проблемы с масштабированием кода и исправлением подхода к крупномасштабным системам
  2. Конкретные технические ограничения времени

Первоначальная поэтапная модель была создана в лаборатории Линкольна Массачусетского технологического института. Их модель состояла из 9 фаз, предназначенных для непосредственного решения проблем, с которыми сталкивались группы разработчиков программного обеспечения в 1950-х годах. Это позволило им масштабировать свои усилия по разработке, делиться информацией о системе и документировать, что пошло не так, чтобы эти знания могли быть переданы существующим и будущим участникам.

В Lincoln Labs использовались следующие фазы:

  1. Оперативный план
  2. Машина и эксплуатационные характеристики
  3. Характеристики программы
  4. Спецификации кодирования
  5. Кодирование
  6. Тестирование параметров
  7. Тестирование сборки
  8. Вымогательство
  9. Оценка системы

Многие варианты SDLC были созданы на разных этапах, которые менялись по мере развития бизнеса и технологий.

Почему SDLC стал проблемой

Проблемы с SDLC возникли по двум причинам:

  1. Организации увеличили количество и сложность этапов в SDLC.
  2. SDLC не поспевает за усовершенствованными инструментами.

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

Первоначально SDLC был представлен для решения двух проблем:

  1. Масштабирование разработки программного обеспечения для работы с крупномасштабными системами
  2. Конкретные технические ограничения времени

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

SDLC научил нас тому, что существует такая вещь, как слишком много процессов.

Capability versus process weight: Compared to code and fix, adding process improves software delivery until the process itself becomes the constraining factor

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

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

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

Любая экономическая модель автоматизации должна учитывать:

  • Увеличенная частота
  • Выше качество
  • Меньше ручных ошибок
  • Снижение стоимости задержки

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

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

Есть ли у DevOps SDLC?

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

Используя SDLC, вы объедините 20 человек в 5 групп специалистов для работы на таких этапах, как анализ, проектирование, разработка, тестирование и эксплуатация. Эти горизонтальные команды выполняли свою специализированную задачу, передавая работу от команды к команде, как эстафетную палочку.

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

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

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

Процесс DevOps

Непрерывная доставка занимает центральное место в процессе DevOps, но вам по-прежнему нужен способ узнать, что нужно создать, и поделиться ими. Ваш выбор будет определяться вашим контекстом, но пример процесса показан ниже:

  1. Карта воздействия: метод совместной разработки идей, связанных с целями.
  2. Спецификация на примерах. Способ изложения требований на примерах, которые можно превратить в автоматические приемочные тесты.
  3. Непрерывная доставка: процесс доставки программного обеспечения, основанный на автоматическом конвейере развертывания.

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

Наследие SDLC

Для некоторых организаций неотъемлемая часть SDLC – это тяжелый набор этапов и элементов управления, которые ограничивают доставку программного обеспечения и создают высокий уровень рыночного риска. Это печальный негативный результат многолетних открытий.

Настоящим наследием SDLC должно быть то, чему мы научились за первые 4 десятилетия поставки программного обеспечения:

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

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

Заключение

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

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


Также опубликовано здесь


Оригинал
PREVIOUS ARTICLE
NEXT ARTICLE