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

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

Что такое SDLC?

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

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

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

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

Зачем был создан SDLC?

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

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

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

• 1989 - Тим Бернерс-Ли изобрел Всемирную паутину.

• 1997 - запущен Google.

• 2008 - появился Stack Overflow.

До появления SDLC системы создавались на лету, по принципу "code-and-fix" (написание кода и устранение ошибок). Не имея определенного процесса или контроля и с множеством технологических ограничений, поэтапная модель решала многие проблемы, с которыми сталкивались организации в то время при создании больших приложений.

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

• Проблемы масштабирования подхода "code-and-fix" для крупномасштабных систем.

• Специфические технические ограничения того времени.

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

В Лаборатории Линкольна использовались следующие фазы:

1. Операционный план;

2. Машинные и эксплуатационные характеристики;

3. Характеристики программы;

4. Характеристики кодирования;

5. Кодирование;

6. Тестирование параметров;

7. Тестирование сборки;

8. Испытания;

9. Оценка системы;

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

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

Проблемы возникли в SDLC из-за двух факторов:

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

2. SDLC не поспевала за развитием инструментами.

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

Изначально SDLC была внедрен, чтобы решать две проблемы:

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

2. Специфические технические ограничения того времени.

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

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

Потенциал против веса процесса: По сравнению с “code-and-fix”, добавление процесса улучшает доставку программного обеспечения до тех пор, пока сам процесс не становится ограничивающим фактором.

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

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

• Увеличение частоты

• Более высокое качество

• Меньшее ручных ошибок

• Снижение стоимости задержки

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

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

Есть ли у DevOps SDLC?

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

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

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

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

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

DevOps процесс

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

1. Составление карты влияния: Техника совместной работы для генерирования идей, связанных с целями.

2. Спецификация на примере: Способ передачи требований с помощью примеров, которые можно превратить в автоматизированные приемочные тесты.

3. Непрерывная поставка: Процесс поставки программного обеспечения, построенный на автоматизированном конвейере развертывания.

Continuous Delivery не зависит от какой-либо конкретной техники генерирования идей. Например, вы можете перейти от “Карты влияния” к “Lean Startup” или любой другой технике из вашего набора инструментов управления продуктом. DevOps подразумевает использование  соответствующих методик Lean и Agile наряду с Continuous Delivery. 

Наследие SDLC

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

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

• Вы должны работать с небольшими частями.

• Развертывание должно происходить часто.

• Начинайте с небольшого рабочего прототипа, а затем развивайте его.

• Можно иметь слишком много процессов.

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

Заключение

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

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