🛠 Архитектура CI/CD с использованием конвейеров Azure Pipelines

Высокоуровневый рабочий процесс DevOps для развертывания изменений в приложениях в средах staging и production в Azure

Данные проходят через такие этапы:

1. Конвейер PR.
Запрос на извлечение (PR) в Azure Repos Git запускает конвейер PR. Этот конвейер выполняет быстрые проверки качества. Эти проверки должны включать:
- Создание кода, требующего извлечения зависимостей из системы управления зависимостями
- Использование инструментов для анализа кода, таких как статический анализ кода и линтинг
- Модульные тесты

2. Конвейер CI.
Слияние с Azure Repos Git запускает конвейер CI. Этот конвейер выполняет те же проверки, что и PR-конвейер, но с некоторыми важными дополнениями. Конвейер CI выполняет интеграционные тесты. Эти интеграционные тесты не должны требовать развертывания решения, поскольку артефакты сборки еще не созданы.

3. Триггер конвейера CD.
Публикация артефактов запускает конвейер CD.

4. Выпуск CD в промежуточную среду.
Конвейер CD загружает артефакты сборки, созданные в конвейере CI, и развертывает решение в промежуточной среде. Затем конвейер запускает приемочные тесты в промежуточной среде для проверки развертывания.

5. Выпуск CD в продакшен

6. Мониторинг.
Azure Monitor собирает данные наблюдения, такие как журналы и метрики, чтобы оператор мог анализировать данные о работоспособности, производительности и использовании.

🔗 Подробнее почитать можно тут

@DevOPSitsec

📌Всё про сортировку веток 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