Проблема, которую все замалчивают

Когда в 2024–2025 году разработчики говорят о CI/CD, в голове сразу возникают образы: GitHub Actions, GitLab CI, Kubernetes, контейнеры. Но у огромного числа компаний — банков, страховых, промышленных предприятий, региональных IT-отделов — вся инфраструктура по-прежнему живёт на Windows Server и IIS. И именно здесь пролегает болезненная зона: современные инструменты деплоя либо не заточены под Windows, либо стоят неприличных денег, либо тянут за собой облачную зависимость.

Именно эту нишу занял fDeploy — инструмент, который появился в треде «Show HN» на Hacker News и моментально привлёк внимание сообщества. Разберём, что он умеет, как устроен и когда стоит его использовать.

Что такое fDeploy и зачем он нужен

fDeploy — это набор Windows-сервисов, спроектированных для упрощения рабочего процесса деплоя IIS-сайтов, веб-приложений и виртуальных директорий, с полным обзором развёртываний и окружений.

Инструмент ориентирован на Windows-команды, доставляющие .NET-приложения на IIS. В него встроены NuGet-репозиторий, OpenAPI v3 REST API, управление конфигурацией IIS и выполнение PowerShell-скриптов. Лицензия — per-server, а не per-target.

Это принципиально важный момент: вы платите за сервер управления, а не за каждую машину-цель. Если у вас 20 серверов IIS — цена не вырастет в 20 раз.

«Self-hosted deployment software for Windows, built in Stockholm» — именно так позиционирует себя команда fDeploy.

ℹ Кому это нужно

fDeploy идеально подходит командам, которые:

  • Работают с .NET Framework или .NET Core на Windows Server
  • Хостят приложения через IIS
  • Не могут или не хотят использовать облачные CI/CD-сервисы
  • Хранят данные строго на собственной инфраструктуре (compliance, регуляторы, ФЗ-152)

Архитектура: как это работает изнутри

fDeploy построен по классической схеме «управляющий сервер + агенты».

fDeploy Server устанавливается на одну машину, fDeploy Agent — на каждый целевой сервер. Облачных компонентов нет; NuGet-фид является частью Server.

Управляющая плоскость работает как один Windows-сервис: дашборд, OpenAPI v3 REST API и NuGet-фид — всё в одном процессе. Он управляет проектами, окружениями, ролями целевых машин, переменными и историей релизов.

На каждой целевой машине работает Windows-сервис (Agent). Пакеты доставляются по аутентифицированному зашифрованному каналу; подстановка переменных, XDT-трансформации, конфигурация IIS и PowerShell выполняются локально на машине.


graph LR
    A[Разработчик
пушит код] --> B[Build Server
собирает .nupkg]
    B --> C[fDeploy Server
NuGet Feed + Dashboard]
    C --> D[fDeploy Agent
Target 1 / IIS]
    C --> E[fDeploy Agent
Target 2 / IIS]
    C --> F[fDeploy Agent
Target N / IIS]
    D --> G[Готово: сайт обновлён]
    E --> G
    F --> G

Роли и окружения

Целевые машины получают роли — например, web-server или app-server — и могут входить сразу в несколько окружений. Шаги деплой-процесса выбирают цели по роли и окружению, поэтому один процесс покрывает все окружения.

Фазовый пайплайн

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

Это гарантирует классическую схему: Dev → Staging → Production без возможности «перепрыгнуть» этап.

Rolling-деплой без даунтайма

IIS-, script- и HTTP-шаги принимают параметр «размер пакета целей». Значение 0 деплоит на все совпадающие цели параллельно (дефолт). Значение 1 — последовательно, что позволяет держать часть инфраструктуры под трафиком. Значение N — деплоит на N целей одновременно.

Ключевые возможности

Встроенный NuGet-репозиторий

fDeploy Server хостит собственный NuGet-фид. Пакеты пушатся в него из билд-системы, и каждая загруженная версия сохраняется.

Это означает полную историю версий «из коробки» и возможность откатиться к любому предыдущему релизу без дополнительных инструментов.

XDT-трансформации и переменные

XDT-трансформации .NET выполняются во время деплоя, с применением подстановки переменных поверх. Конфигурация, специфичная для окружения, остаётся вне сборки.

Это решает одну из главных болей .NET-разработчиков: больше не нужно хранить Web.Production.config в репозитории или городить костыли в пайплайне.

Управление сертификатами

Сертификаты хранятся централизованно и привязываются к IIS-сайтам в рамках деплой-процесса. Agent устанавливает сертификат по thumbprint и пропускает уже присутствующий, так что повторный деплой идемпотентен.

Безопасность

Server и Agent аутентифицируют друг друга по зашифрованному каналу. Пакеты, разрешённые переменные и скрипты передаются через него. Чувствительные переменные шифруются в хранилище и маскируются в логах.

Разграничение прав

Права назначаются командам, а не отдельным пользователям, с ролями, ограниченными по проектам, окружениям или системой в целом. Команды могут быть сопоставлены с группами Active Directory для синхронизации членства.

REST API

Экземпляр fDeploy отдаёт собственный OpenAPI v3-документ. Дашборд является клиентом того же REST API, поэтому клиентские библиотеки для пайплайнов можно сгенерировать прямо из спецификации.

💡 Совет по интеграции
Используйте сгенерированный OpenAPI-клиент для запуска деплоя прямо из вашего CI-инструмента (Jenkins, TeamCity, Azure DevOps) через HTTP-вызов — без установки дополнительных плагинов.

fDeploy vs. конкуренты

Сравним fDeploy с ближайшими альтернативами для Windows/IIS-окружений:

ПараметрfDeployOctopus DeployAzure DevOps (облако)GitHub Actions (self-hosted)
ПлатформаWindowsWindows/LinuxОблако/On-premЛюбая
ЛицензияPer-serverPer-targetPer-user/minБесплатно + минуты
Облачная зависимость❌ НетОпционально✅ ДаОпционально
Встроенный NuGet✅ Да✅ Да❌ Нет❌ Нет
IIS из коробки✅ Да✅ ДаЧерез задачиЧерез скрипты
XDT-трансформации✅ Да✅ ДаВручнуюВручную
Управление сертификатами✅ Да✅ ДаЧерез Key VaultВручную
AD-интеграция✅ Да✅ Да✅ Да❌ Нет
Стоимость входаНизкаяВысокаяСредняяНизкая

Ближайшей альтернативой fDeploy является Octopus Deploy — зрелый, функциональный инструмент, но его модель ценообразования per-target делает его дорогим при росте инфраструктуры.

⚠ Ограничения fDeploy

Перед выбором учтите:

  • Нет мультитенантности — один экземпляр Server на установку
  • Нет кластерной отказоустойчивости — единая точка отказа на уровне Server
  • Инструмент ориентирован только на Windows-инфраструктуру

Практический сценарий: деплой ASP.NET-приложения

Рассмотрим типовой рабочий процесс с fDeploy на конкретном примере.

Шаг 1. Упаковка приложения в NuGet-пакет

В CI-пайплайне (например, в Azure DevOps или TeamCity) добавляем шаг упаковки:

# Сборка и упаковка .NET-приложения
dotnet publish ./MyApp/MyApp.csproj `
    --configuration Release `
    --output ./publish

# Создание NuGet-пакета
nuget pack MyApp.nuspec -Version 1.0.$BUILD_NUMBER

# Публикация в fDeploy NuGet Feed
nuget push MyApp.1.0.$BUILD_NUMBER.nupkg `
    -Source http://fdeploy-server:5000/nuget `
    -ApiKey $FDEPLOY_API_KEY

Шаг 2. Создание релиза через REST API

# Создать релиз и запустить деплой на Staging
$body = @{
    projectId  = "my-app"
    version    = "1.0.$BUILD_NUMBER"
    deployTo   = "staging"
} | ConvertTo-Json

Invoke-RestMethod `
    -Uri "http://fdeploy-server:5000/api/releases" `
    -Method POST `
    -Body $body `
    -ContentType "application/json" `
    -Headers @{ Authorization = "Bearer $FDEPLOY_TOKEN" }

Шаг 3. Что происходит на целевом сервере

Agent принимает пакет по зашифрованному каналу и локально выполняет подстановку переменных, XDT-трансформации, конфигурацию IIS и PowerShell-скрипты.

Последовательность автоматически:

  1. Останавливает Application Pool
  2. Разворачивает пакет в папку сайта
  3. Применяет Web.config трансформации для окружения
  4. Запускает кастомный PowerShell-скрипт (опционально)
  5. Запускает Application Pool обратно
  6. Регистрирует результат в дашборде

Шаг 4. Snapshot релиза

Создание релиза фиксирует снимок деплой-процесса, значений переменных и ссылок на пакеты, включая значения из связанных библиотечных наборов переменных.

Это гарантирует воспроизводимость: деплой одного и того же релиза через месяц даст идентичный результат.

📝 Пример XDT-трансформации

Для переопределения строки подключения в Production достаточно файла Web.Production.config:

<?xml version="1.0"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <connectionStrings>
    <add name="Default"
         connectionString="#{DB_CONNECTION_STRING}"
         xdt:Transform="SetAttributes"
         xdt:Locator="Match(name)" />
  </connectionStrings>
</configuration>

Значение #{DB_CONNECTION_STRING} подставится из зашифрованных переменных fDeploy автоматически.

Почему это появилось на Hacker News и получило отклик

Проект появился в треде «Show HN» и вызвал живую дискуссию — и не случайно. Он поднимает реальную проблему: экосистема DevOps за последние 10 лет сфокусировалась на Linux и контейнерах. IIS для Windows Server — это гибкий, безопасный и управляемый веб-сервер, способный хостить что угодно, от медиастриминга до сложных веб-приложений, однако нормальных инструментов автоматизации для него катастрофически мало.

Web Deploy (MSDeploy) — официальный инструмент Microsoft для синхронизации веб-приложений, баз данных и конфигураций IIS между серверами, — но он не решает задачу оркестрации: кто, когда и куда деплоит, с каким approval-процессом и аудитом.

В fDeploy Server, репозиторий пакетов и агенты — всё работает на собственном железе. Никаких облачных компонентов и исходящих проверок лицензии. Именно это оценивают команды, которые работают в закрытых контурах.

Заключение

fDeploy закрывает реальный пробел на рынке: для команд на Windows + IIS до него выбор был невелик — либо дорогой Octopus Deploy с ценообразованием per-target, либо самописные скрипты PowerShell, либо попытки натянуть GitHub Actions на Windows-окружение.

Инструмент не претендует на универсальность: он явно Windows-центричен и не подходит для контейнерной инфраструктуры. Но именно в своей нише — .NET-приложения на IIS, закрытые контуры, on-prem — он предлагает хорошо продуманную архитектуру: зашифрованный канал между Server и Agent, фазовые пайплайны, встроенный NuGet, XDT-трансформации, AD-интеграцию и rolling-деплой без даунтайма.

Когда стоит попробовать fDeploy:

  • Ваша команда деплоит .NET на IIS вручную или через скрипты
  • Вы работаете в закрытом контуре без доступа к облакам
  • Octopus Deploy слишком дорог для вашего масштаба
  • Вам нужен audit trail и approval-процесс для деплоев

Когда не стоит:

  • Ваша инфраструктура контейнеризована (Kubernetes, Docker)
  • Вы работаете на Linux-серверах
  • Вам нужна HA-конфигурация управляющего сервера

Документация доступна на docs.fdeploy.com, а исходная дискуссия на Hacker News — отличный срез реальных кейсов от людей, которые живут с этой болью каждый день.