Ускорение выпуска программного обеспечения создает необходимость непрерывной интеграции и непрерывной доставки. «По прошествии трех недель вы забыли, что вообще построили эту штуку».
Давайте посмотрим правде в глаза: темпы выпуска программного обеспечения становятся все более стремительными. Два года назад 35% предприятий, ответивших на опрос Cloud Native Computing Foundation, выпускали программное обеспечение ежедневно или еженедельно. В последнем выпуске CNCF опрос, это число выросло до 65%. Число респондентов с ежедневным циклом выпуска за это время увеличилось с 15% до 27%.
В оживленных центрах разработки программного обеспечения здорово иметь по-настоящему умных, квалифицированных людей, которые действительно хороши в разработке элегантных решений для бизнеса. Но поскольку релизы выходят ежедневно, а может быть, даже ежечасно, даже лучшим из лучших сложно оставаться в курсе этого процесса, который часто предполагает возвращение к исправлениям.
Вот почему необходимо срочно внедрить отлаженную и высокоавтоматизированную систему.
непрерывная интеграция/непрерывная доставка (CI/CD), по мнению Эндрю Дэвиса из Copado и автора Освоение DevOps Salesforce. В убедительном сессия На Dreamforce 19 он обрисовал проблемы, с которыми сейчас сталкиваются предприятия, отметив, что эффективное ускорение жизненного цикла разработки «требует координации мышления и хороших инструментов».Хотя выступление Дэвиса было адресовано командам Salesforce, его идеи нашли отклик и в более широкой сфере ИТ. Обычно, по его словам, развертывание программного обеспечения состоит из шести этапов, которые составляют основу DevOps:
- Поймите, что нужно пользователям.
- Построить это.
- Убедитесь, что это работает.
- Убеждается, что все работает хорошо со всем остальным.
- Убедитесь, что вы больше ничего не сломали.
- Разверните его для пользователей.
По словам Дэвиса, на последних трех шагах многие команды разработчиков склонны спотыкаться. «Самое блаженство в написании кода или выполнении сложной административной задачи и т. д. — это когда все у тебя в голове и ты видишь, как все сходится воедино, и мир исчезает, и вы точно знаете, как работает ваша организация, и любой может попросить о любых изменениях, и вы можете это исправить. вещи. Разработчики живут ради этого блаженного чувства — знать все и все исправить».
Загвоздка в том, что конкретный проект заканчивается, отвлекающие факторы отвлекают, начинаются новые проекты, и время идет, продолжает Дэвис. «Это исчезает из вашей рабочей памяти, верно? Может пройти день, неделя или месяц, прежде чем вы узнаете, что что-то сломали. По прошествии трех недель вы забыли, что вообще построили эту штуку. И если вы помните, что вы это построили, вы забываете, как вы это построили, вы забываете, почему вы это построили. Конечно, вы можете внести еще одно изменение, но тогда вам может потребоваться еще три недели, прежде чем вы сможете вернуть его своим пользователям».
Умножьте это на сотни или даже тысячи запросов на изменения внутри крупной организации, и легко увидеть, как все может пойти наперекосяк.
DevOps вносит порядок и поток в это потенциальное безумие, и Дэвис сводит его к трехэтапному процессу: разработка, внедрение инноваций и эксплуатация. «Есть этап разработки, где вы создаете что-то новое, и этап эксплуатации, когда вы запускаете материал в производство», — говорит Дэвис. «Затем между ними есть процесс внедрения инноваций, который внедряет все эти замечательные инновации в производство». Вот почему очень необходим автоматизированный процесс DevOps, чтобы исключить и систематизировать ручную работу, необходимую для среднего этапа между разработкой и операции.
Дэвис проиллюстрировал, как должна выглядеть эффективная стратегия DevOps и CI/CD:
- Каждый разработчик и команда в компании по крайней мере ежедневно сливаются в общий ствол или базу кода.
- Как только база кода меняется, он запускает автоматические тесты.
- Если тесты проваливаются или что-то ломается, это исправляется в течение десяти минут.
По словам Дэвиса, способность автоматизировать этап тестирования и проводить быстрые тесты является ключом к усилиям по CI/CD. «Разработчикам нужны быстрые тесты, где они смогут получить обратную связь, пока в их рабочей памяти еще есть все эти потрясающие возможности». Эти тесты должны быть спроектирован так, чтобы давать разработчикам «обратную связь, близкую к реальному времени, менее чем за пять минут». Более комплексное модульное тестирование может следовать.
Аспект непрерывной доставки также должен решить еще одну возникающую проблему, называемую «дрейфом конфигурации», при которой «среды рассинхронизируются по множеству причин», — сказал Дэвис. «Возможно, люди вносят изменения в производство, которые не возвращаются к разработке и тестированию. Или вы изменили среду разработки, но в вашей «песочнице» для разработки лежит куча мусора, который у вас есть с 2006 года и который не обновляется, и вы знаете, что он не совсем соответствует рабочей среде».