💻 Девопс-2024: чего ожидать и что изменится

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


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

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


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

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


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

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

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


⏩Упрощение и рост доступности Kubernetes
Kubernetes — это система управления приложениями, которые работают друг с другом и решают задачи в одном контейнере, который работает как виртуальная машина. Но для многих сложность управления Kubernetes остаётся препятствием для её использования. Поэтому ожидается, что платформа будет меняться в сторону упрощения, чтобы разработчики могли использовать возможности Kubernetes, не будучи экспертами в тонкостях её работы.Kubernetes: что нужно знать, чтобы получать 350 000 в месяц

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


⏩Развитие low-code и зеро-кода
Платформы low-code и зеро-код — это инструменты, которые позволяют пользователям создавать приложения с минимальным использованием кода или без его написания.

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


Вот мы и обсудили, в каком направлении движется DevOps
А что вы думаете по этому поводу?

@DevOPSitsec

🖥 Управление GitHub-репозиториями: best practices

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


〰️ Четко придерживайтесь соглашения об именовании репозиториев

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

⏩Описательные имена. Репозитории должны иметь описательные и конкретные названия, которые подскажут вам, что в них находится. Например, customer_support_ticketing_system или machine_learning_model_trainer.

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

⏩Версии или метки состояния. Если вы поддерживаете разные версии инструмента или библиотеки, или если в репозитории хранится что-то на определенной стадии разработки, укажите это в названии. Например, payment_gateway_v2 или inventory_management_deprecated.

⏩Избегайте специальных символов. Придерживайтесь букв и цифр с дефисами и символами подчеркивания, чтобы сохранить URL-совместимость и избежать путаницы. Например, invoice-generator или invoice_generator.

⏩Указание на юзкейс. Иногда полезно указать, является ли репозиторий библиотекой, сервисом, демо-версией или документацией. Например, authentication_lib, payment_api_service, demo_inventory_app, api_documentation.


〰️ Классифицируйте репозитории по темам

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

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

⏩Сообщество. Указание тем поможет вам познакомиться с людьми, которые интересуются теми же темами. Когда кто-то просматривает репозиторий с определенной темой, он может увидеть другие репозитории с той же темой.

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

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


〰️ Используйте README.md для документирования репозитория

Хорошо написанный файл README.md может вам помочь в следующих вещах:
⏩Привлечение контрибьюторов. Этот файл предоставляет потенциальным контрибьюторам информацию, необходимую для понимания проекта и начала работы с ним.

⏩Онбординг. README.md поможет новым членам команды освоиться в проекте.

⏩Документация. Файл README.md служит документацией для проекта. Он предоставляет пользователям информацию, необходимую для работы с проектом.

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

⏩Стандартизация. README.md помогает стандартизировать способ документирования проектов. Это обеспечивает последовательную структуру документирования проектов.

📎 Ещё 7 полезных советов

@DevOPSitsec

🌟 Вышел WingetUI (UnigetUI) 3.0

⏩13 марта 2024 года состоялся релиз WingetUI (UnigetUI) 3.0. Это графический инструментарий с открытым исходным кодом, который позволяет устанавливать, удалять и обновлять приложения на устройствах Windows с помощью наиболее распространённых консольных менеджеров (CLI) для Windows 10 и Windows 11, включая Windows Package Manager (winget), Scoop и Chocolatey, а также Pip, Npm, .NET Tool и PowerShell Gallery.

⏩Фактически WingetUI превратился в поддержку различных менеджеров пакетов, а не только Winget, что привело к тому, что имя WingetUI сбивает с толку новых пользователей и не отражает основную суть этого приложения. В настоящее время в WingetUI доступно более 14 тыс. пакетов (Winget, Scoop и Chocolatey).
Автор проекта Марти Климент пояснил, что он с каждым днём наблюдает, как пользователи всё чаще путают WingetUI и winget, что вполне ожидаемо, учитывая небольшую разницу между этими двумя названиями. Поэтому WingetUI скоро будет переименован в UnigetUI.

@DevOPSitsec

📌20 полезных, но малоиспользуемых команд Git

Держите, это кликабельный список:
⏩ Git Web — открыть встроенный графический интерфейс
⏩ Git Notes — прикрепить дополнительную информацию к коммитам
⏩ Git Bisect — дебажить как про
⏩ Git Grep — найти что угодно
⏩ Git Archive — сжать проект для шеринга
⏩ Git Submodules — импортировать другие репозитории в ваш
⏩ Git Bugreport — скомпилировать баг-репорт с информацией о системе
⏩ Git Fsck — проверить и восстановить недоступные объекты
⏩ Git Stripspace — удалить пробелы в конце текста
⏩ Git Diff — сравнить изменения между двумя файлами
⏩ Git Hooks — выполнить скрипт при запуске команды git
⏩ Git Blame — показать, кто написал данную строку
⏩ Git Large File Storage — сохранить большие файлы в git
⏩ Git Garbage Collection — оптимизировать git-репо
⏩ Git Show — легко просмотреть любой объект git
⏩ Git Describe — дать читаемое имя на основе последнего тега
⏩ Git Tag — создать метки версий в определенных точках
⏩ Git Reflog — список всех действий, выполненных над репозиторием
⏩ Git Log — просмотреть журнал коммитов и диаграммы ветвей
⏩ Git Cherry Pick — вытащить фичу в вашу ветку
⏩ Git Switch — быстро переключиться между ветками

Пользуйтесь)

@DevOPSitsec

💻 Лучшие практики работы с Kubernetes

Держите, остаётся самое сложное — следовать этим практикам)

📎 А вот полезная статья в тему, где подробно рассказывается о каждом из правил

@DevOPSitsec

💻 Будущее Kubernetes и DevOps: строим прогнозы на 10 лет

Полезная статья, в ходе которой опросили инженеров «Фланта» и экспертов из индустрии, как, по их мнению, будут развиваться Kubernetes, DevOps, Ops и Cloud Native-экосистема в ближайшее десятилетие.

Цель статьи — спрогнозировать будущее на основе тенденций в настоящем.

Вот вопросы, которые освещаются:
⏩Будет ли еще популярен Kubernetes через 5–10 лет? Какие технологии могут прийти ему на смену? Какие вызовы ему придется решать?

⏩Будет ли ещё DevOps? Как изменится его понимание? Как изменится культурный аспект, стоящий за DevOps-практиками? Как могут измениться сами практики?

⏩Какие интересные, необычные Ops'ы могут появиться? Какие задачи они будут решать?

⏩Что станет с Cloud Native-экосистемой и программами внутри нее? Какие проблемы она должна будет научиться решать? Какие новые программы могут появиться в ней? Что станет с облаками? Как они изменятся? Придет ли какая-то другая технология на смену облакам, и если да, то какой примерно она будет?

📎 Статья

@DevOPSitsec