Общий исходный код
Начните с общего Git-источника и сохраните точный commit и понятную версию, связанные с релизом. Разные типы развертывания могут развиваться независимо, оставаясь привязанными к одной истории исходного кода.
Доставка ПО
От общего исходного кода к контролируемому развертыванию.
Возможности доставки ПО Microwave Pie созданы, чтобы упростить внедрение самостоятельно размещаемых приложений: управляйте релизами из общего источника, создавайте подходящий пакет для развертывания, применяйте лицензирование и сохраняйте связь установки и обновлений с известным релизом.
Общая модель доставки
1Общий исходный код приложенияЕдиная история исходного кода и идентичность релиза.
2Релиз платформыСборка для нужной цели развертывания.
Исходный пакет
Скомпилированный пакет
3Лицензированный пакетВыпустить пакет для конкретного внедрения.
4Установка и обновлениеСохраняйте историю развертывания связанной с поставленным релизом.
Возможности
Сохраняйте гибкость выбора релизов без потери контроля.
Разным средам не всегда нужен один и тот же формат пакета или один и тот же релиз одновременно. Microwave Pie разделяет общий исходный код приложения, переиспользуемые релизы, пакеты, лицензии и установленные экземпляры, чтобы каждым аспектом можно было управлять осознанно.
Исходные пакеты
Поставляйте приложение в исходном виде, если важнее прозрачность, непосредственное развертывание в среде выполнения или платформенная установка Python. Исходные пакеты используют ту же модель релизов и лицензирования, что и скомпилированные.
Скомпилированные пакеты
Поставляйте скомпилированный пакет, если предпочтительна более автономная среда выполнения. Компиляция — это вариант доставки, а не отдельная продуктовая ветка, поэтому происхождение релиза остаётся единым.
Управление пакетами и лицензиями
Выпускайте пакет уже с привязанной лицензией и контекстом целевого развертывания. Жизненным циклом пакета, состоянием лицензии, загрузками, установками, обновлениями, отзывом и закрытием можно управлять вместе, а не восстанавливать эти сведения позднее.
Выбор релизов под конкретные цели
При необходимости развертывания Raspberry Pi, GCP, исходного и скомпилированного типов могут оставаться на разных уровнях релиза. Отсутствующие Git commits можно просматривать по типам развертывания и по всему приложению.
Обновления из UI
Управляемые приложения могут автоматически сообщать о доступном одобренном обновлении, не навязывая его. Администратор выбирает в UI приложения, когда подготовить и применить обновление; после перезапуска установленный релиз можно подтвердить в общей службе доставки, сохранив связь Package и License.
Внедрение
Упаковывайте развертывание, а не неопределённость.
Пакет ПО может содержать контекст внедрения, необходимый для превращения релиза приложения в рабочее развертывание: целевую платформу, формат пакета, поведение установки, идентичность релиза и лицензионную связь.
Это позволяет начинать внедрение с известного релиза, вместо того чтобы каждая среда заново воспроизводила решения по сборке и доставке. Когда нужен новый релиз, существующая связь Package и License может сохраниться, а выбранный релиз — продвигаться контролируемо.
Application Releases сохраняют фактически собранный артефакт и Git-идентичность.
О доступности можно сообщать автоматически, но загрузка, подготовка, применение и перезапуск остаются осознанными действиями администратора.
Пакеты, лицензии и установленные экземпляры остаются связанными на протяжении установки, обновления, отзыва и закрытия.
Blackcap
Сегодня эту модель использует одно приложение.
Blackcap можно развернуть в поддерживаемых средах Raspberry Pi и GCP с помощью исходных или скомпилированных пакетов, сохраняя согласованность релизов, пакетов, лицензий и обновлений.