3. Ориентированность на приложения

Обновлено: 2024-03-12

6 мин

Содержание

Жизненный цикл DevOps — ориентированность на приложения

По мере того, как мы будем продолжать в течение следующих нескольких недель, мы будем сталкиваться с этими названиями (Continuous Development, Testing, Deployment, Monitor) (непрерывная разработка, тестирование, развертывание, мониторинг) снова и снова. Если вы стремитесь статья инженером DevOps, то повторяемость будет тем, к чему вы привыкнете, но постоянное улучшение каждый раз — это еще одна вещь, которая делает вещи интересными.

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

Разработка

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

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

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

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

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

Также вероятно, что над этим проектом будет работать не один разработчик, хотя это может иметь место, но даже в этом случае передовой опыт потребует репозиторий кода для хранения и совместной работы над кодом, он может быть частным или общедоступным и может быть размещен или если говорить о частном развертывании, вы наверняка слышали, как GitHub или GitLab используются в качестве репозитория кода. Мы снова рассмотрим их позже в разделе Git.

Тестирование

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

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

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

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

Интеграция

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

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

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

Я бы также сказал, что очень важно просто иметь эти вышеперечисленные знания, поскольку сегодня вы можете купить готовое программное обеспечение, но что насчет завтра или в будущем … может быть, на следующей работе?

Развертывание / Deployment

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

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

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

Мониторинг / Monitoring

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

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

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

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

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

Источники

Я всегда открыт для добавления дополнительных ресурсов в эти файлы readme, поскольку они здесь в качестве учебного пособия.

Мой совет — посмотрите все, что ниже, и, надеюсь, вы тоже что-то почерпнули из текста и объяснений выше.

До встречи в День 4