Ответ
Ответственность за деплой (развертывание) варьируется в зависимости от зрелости процессов команды и её структуры.
Основные модели:
-
DevOps / Platform Engineering: В современных CI/CD-практиках ответственность лежит на разработчиках, а инженеры DevOps или Platform обеспечивают и поддерживают надежные, самообслуживаемые пайплайны и инфраструктуру. Разработчик создает Pull Request, который после мержа автоматически проходит сборку, тестирование и деплой в staging/production через настроенный пайплайн.
-
Выделенный инженер DevOps: В некоторых командах инженер DevOps настраивает пайплайны и выполняет ручные или полуавтоматические деплои, особенно для сложных или критичных сред.
-
Релиз-менеджер: В крупных корпоративных средах с жестким контролем релизов может быть отдельная роль, координирующая выкатку между командами, утверждающая план и проводящая откат при необходимости.
Пример автоматизированного пайплайна (GitHub Actions для .NET приложения):
name: Build, Test and Deploy
on:
push:
branches: [ main ]
jobs:
build-and-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup .NET
uses: actions/setup-dotnet@v4
- name: Restore dependencies
run: dotnet restore
- name: Build
run: dotnet build --configuration Release --no-restore
- name: Run tests
run: dotnet test --configuration Release --no-build --verbosity normal
deploy-to-staging:
needs: build-and-test
runs-on: ubuntu-latest
if: success()
environment: staging
steps:
- uses: actions/checkout@v4
- run: dotnet publish -c Release -o ./publish
- name: Deploy to Azure Web App
uses: azure/webapps-deploy@v3
with:
app-name: 'my-app-staging'
publish-profile: ${{ secrets.AZURE_PUBLISH_PROFILE_STAGING }}
package: ./publishИдеальная цель: Полностью автоматизированный, надежный и откатываемый процесс деплоя, где разработчик может безопасно выкатить изменения без глубокого знания инфраструктуры.
Ответ 18+ 🔞
Давай разберемся, кто же в итоге должен жать на эту красную кнопку, чтобы всё полетело в прод. А то вечно непонятно — то ли ты, то ли какой-нибудь дядька с бородой из соседнего отдела.
Короче, есть три основных подхода, и все они — пиздец как разные:
-
DevOps / Platform Engineering (Модно и правильно). Тут вся ответственность — на тебе, разработчике. Ты написал код, замержил его в
main, а дальше магия: пайплайн сам всё собирает, тестирует и выкатывает. Эти ребята из Platform только делают так, чтобы эта магия работала без сбоев, а ты не ебал мозг с настройкой серверов. Идеал — ты даже не задумываешься, как это работает, просто пушишь и всё живёт. -
Отдельный инженер DevOps (Старая школа, но ещё жива). Бывает, что пайплайн настроил какой-то гуру, а запускает его вручную он же, особенно если продакшн — это священная корова, до которой можно только с молитвой. Ты сдал артефакт, а дальше ждёшь, пока этот шаман проведёт ритуал деплоя в четыре утра.
-
Релиз-менеджер (Ад бюрократии, обычно в банках или огромных конторах). Тут вообще отдельная песня. Есть специальный человек, который только тем и занимается, что согласует твой релиз с другими двадцатью командами, утверждает план на полгода вперёд и имеет право на откат, если что-то пошло не так. Скорость — как у танка в болоте, зато "безопасно".
Вот, смотри, как это выглядит в жизни, на примере GitHub Actions для .NET:
name: Build, Test and Deploy
on:
push:
branches: [ main ]
jobs:
build-and-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup .NET
uses: actions/setup-dotnet@v4
- name: Restore dependencies
run: dotnet restore
- name: Build
run: dotnet build --configuration Release --no-restore
- name: Run tests
run: dotnet test --configuration Release --no-build --verbosity normal
deploy-to-staging:
needs: build-and-test
runs-on: ubuntu-latest
if: success()
environment: staging
steps:
- uses: actions/checkout@v4
- run: dotnet publish -c Release -o ./publish
- name: Deploy to Azure Web App
uses: azure/webapps-deploy@v3
with:
app-name: 'my-app-staging'
publish-profile: ${{ secrets.AZURE_PUBLISH_PROFILE_STAGING }}
package: ./publishСуть в чём? В идеальном мире ты должен стремиться к первому варианту. Чтобы процесс был настолько автоматизированным и надёжным, что ты можешь выкатывать хоть десять раз в день, не держа в штанах кирпич. Сделал мерж — и забыл, система сама всё сделает, а если что-то сломается — сама же и откатится. Мечта, а не работа.
