📌Всё про сортировку веток Git

Запустив git branch в репозитории, вы обычно получаете список веток в алфавитном порядке. Это может раздражать, когда у вас много веток (если только у вас нет очень жесткой системы именования по номеру тикета или чего-то подобного).
⏩Не проблема, это можно изменить. Выполните в вашем репозитории следующую команду:

git branch --sort=-committerdate

Это отсортирует все ваши ветки по дате их последнего коммита

Для сортировки доступны такие опции:
- authordate
- committerdate
- creatordate
- objectsize
- taggerdate

⏩Кроме того, если хотите всегда сортировать по одному из этих параметров, можно установить это в настройках:

git config --global branch.sort -committerdate

⏩Также можно задать псевдоним:

git config --global alias.brcd "branch --sort=-committerdate".

Подробнее о работе с ветками можно почитать тут, ловите ссылки:
📎 Ветвление Git с примерами из реальной жизни
📎 Как удалить ветку в Git
📎 Как переименовать локальную ветку в Git

@DevOPSitsec

🔄Как упростить работу с YAML-файлами

YAML — популярный язык для конфигурационных файлов, широко используемый DevOps в подходе «Инфраструктура как Код» (IaC).
Давайте рассмотрим несколько советов, которые помогут упростить работу с yml-файлами.


Используйте специализированные редакторы и плагины
Очевидный совет, но мало ли; работа с YAML в правильной среде даёт:
🔘подсветку синтаксиса
🔘автодополнение кода
🔘проверку отступов
🔘сниппеты (шаблоны кода)

Популярные плагины: YAML Support для VS Code, yaml-mode для Emacs, drawspaces для Gedit.


Генерируйте YAML из кода
Ручное написание сложных конфигураций на YAML не так приятно. Проще сначала определить нужную структуру данных в виде словарей и массивов в том же Python, а затем сгенерировать из нее YAML.

Есть такая структура:

data = {
  "server": {
    "port": 8000,
    "enabled": true
  },
  "clients": [
    {"name": "Client1", "address": "192.168.1.100"}, 
    {"name": "Client2", "address": "192.168.1.101"}
  ]
}

С помощью PyYAML легко конвертируем в YAML-файл:

import yaml
with open('config.yaml','w') as f:
  f.write(yaml.dump(data))

Получаем:

  
server:
  port: 8000
  enabled: true
clients:
- address: 192.168.1.100
  name: Client1  
- address: 192.168.1.101
  name: Client2

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

Например, при развертывании микросервисов в Kubernetes удобно иметь шаблон манифеста deployment.yaml:

apiVersion: apps/v1
kind: Deployment 
metadata:
  name:  <service_name> 
  labels:  
    app: <service_name>
spec:
  replicas: 3
  template:
    metadata: 
      labels:
        app: <service_name>                
    spec:
      containers:
      - name: <service_name> 
        image: <image>:<tag>
        ports:
        - containerPort: <port> 
---        
apiVersion: v1
kind: Service

▶️ Ещё несколько полезных советов по YAML

@DevOPSitsec

🌟 Вышел OpenSSH 9.7

Вышел проект OpenSSH 9.7. В новой версии открытой реализации клиента и сервера для работы по протоколам SSH 2.0 и SFTP началось внесение изменений, предшествующих будущему прекращению поддержки ключей на базе алгоритма DSA.

⏩В OpenSSH 9.7 предоставлена опция для отключения DSA на стадии компиляции, но сборка по умолчанию с поддержкой DSA пока сохранена. В следующем выпуске режим сборки будет изменён на отключение DSA по умолчанию, а в начале 2025 года реализация DSA будет удалена из кодовой базы проекта.

⏩В новом выпуске OpenSSH предложен новый тип таймаутов в ssh и sshd, включаемый через указания значения global в директиве ChannelTimeout. В этом режиме OpenSSH отслеживает все открытые каналы и закрывает их разом, если во всех из них за указанный промежуток времени отсутствовал трафик. Например, когда к хосту одновременно открыты каналы для SSH-сеанса и перенаправления x11, новый режим позволяет закрыть сразу оба канала, если они неактивны, вместо раздельного отслеживания таймаутов для каждого канала.

⏩Также из изменений в OpenSSH 9.7 отмечается значительное улучшение тестирования совместимости с проектом PuTTY.

@DevOPSitsec

💻 Девопс-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