Pipeline heroku что это

Как развернуть проект на Heroku

O днажды, когда вы закончите разработку проекта, вам понадобится отправить его на продакшн. То есть, найти хостинг, залить туда файлы, добавить настройки, запустить сайт и так далее. Чтобы вы потом не бегали с горящей задницей, не зная что делать, я подготовил полноценную инструкцию, которая решит все эти проблемы.

Сегодня мы будем деплоить проект, написанный на Svelte, в облачную PaaS-платформу – Heroku. Будем называть её просто “хостинг”.

Начнем с создания базовой структуры, то есть с чистого листа.

За основу возьмем этот бойлерплейт: svelte-boilerplate

Склонируем проект в нужную папку.

git clone https://github.com/pankod/svelte-boilerplate.git svelte

Перейдем в директорию svelte и запустим команду для установки зависимостей

cd svelte && npm install

npm run start:dev

Если всё прошло успешно, сайт будет доступен по ссылке, откроем её в браузере.

Теперь попробуем собрать проект. По идее у нас должна создаться папка public, в которой будут html, css и js файлы, они будут сжаты и оптимизированы, их мы и будем использовать на продакшне.

Команда для сборки проекта

npm run build

Итог должен быть таким:

Подготовка сервера

Скажу сразу: запускать проект на хостинге через команду npm run start:dev плохая идея. Вот почему:

1. Файлы и картинки не будут оптимизированы и сжаты
2. Сервер для разработки не стабилен и не предназначен для больших нагрузок
3. Нет возможности добавить настройки для сервера
4. И куча других проблем.

Мы же сделаем всё как надо и запустим наш проект на простеньком Express.js сервере.

npm i express

В корне проекта создадим файл server.js, в него поместим код ниже

const express = require('express');
const app = express();
const path = require('path');const port = process.env.PORT || 5000;app.use(express.static('public'));app.get('*', (req, res) => res.sendFile(path.resolve(__dirname, 'public', 'index.html'));
>);app.listen(port, () => 
console.log(`Server is running on: http://localhost:$`));

Главное – указать переменную с портом, чтобы Heroku мог подставить нужный порт при старте.

const port = process.env.PORT || 5000;

А так сервер очень простой, при запуске он всего лишь будет рендерить index.html из папки public. Проверим

node server.js

В консоли должно появиться сообщение об успешном старте

И если перейти по ссылке, мы увидим стартовую страницу сайта.

С файлами для продакшна разобрались, сервер подготовили, далее займемся настройкой Heroku CLI.

Установка и настройка Heroku CLI

Heroku CLI – это консольная утилита для удаленной работы с Heroku.

Начнем с установки. У них на сайте есть подробная инструкция . Идём читать.

Обычно раздела “Download and install” достаточно

Пробуем установить. Если всё нормально, наберём в консоли команду heroku. Результат должен быть примерно таким

> heroku
CLI to interact with HerokuVERSION 
heroku/7.49.0 linux-x64 node-v12.16.2USAGE 
$ heroku [COMMAND]COMMANDS 
access manage user access to apps 
addons tools and services for developing, extending, and operating your app 
apps manage apps on Heroku 
auth check 2fa status 
authorizations OAuth authorizations 
autocomplete display autocomplete installation instructions 
buildpacks scripts used to compile apps 
certs a topic for the ssl plugin 
ci run an application test suite on Heroku 
clients OAuth clients on the platform 
config environment variables of apps 
container Use containers to build and deploy Heroku apps 
domains custom domains for apps 
drains forward logs to syslog or HTTPS 
features add/remove app features 
git manage local git repository for app 
help display help for heroku 
keys add/remove account ssh keys 
labs add/remove experimental features 
local run Heroku app locally 
logs display recent log output 
maintenance enable/disable access to app 
members manage organization members 
notifications display notifications 
orgs manage organizations 
pg manage postgresql databases 
pipelines manage pipelines 
plugins list installed plugins 
ps Client tools for Heroku Exec 
psql open a psql shell to the database 
redis manage heroku redis instances 
regions list available regions for deployment 
releases display the releases for an app 
reviewapps manage reviewapps in pipelines 
run run a one-off process inside a Heroku dyno 
sessions OAuth sessions 
spaces manage heroku private spaces 
status status of the Heroku platform 
teams manage teams 
update update the Heroku CLI 
webhooks list webhooks on an app

Это говорит нам о том, что Heroku доступен и готов к работе. Попробуем с помощью него запустить наш сервер. Так же в корне проекта, где находится файл server.js, запустим команду

heroku local web

У меня результат такой. Сайт работает

> heroku local web
[WARN] ENOENT: no such file or directory, open 'Procfile'
[OKAY] package.json file found - trying 'npm start'
8:10:03 PM web.1 | > @pankod/svelte-boilerplate@0.0.1 start
8:10:03 PM web.1 | > node server.js
8:10:03 PM web.1 | Server is running on: http://localhost:5000

Далее в корне проекта нужно создать Procfile. Он поможет определить, как запустить приложение. Heroku в первую очередь будет искать именно его. Если в проекте отсутствует этот файл, heroku попытается запустить веб-сервер с помощью стартового скрипта (npm start) в вашем package.json.

Вставим кусок кода в Procfile

web: node server.js

И попытаемся снова запустить сайт

На этот раз никаких ошибок в консоли нет.

Ну и последним шагом добавим в package.json команду для сборки проекта на стороне heroku

"heroku-postbuild": "npm run build"

Подготовка проекта

Ну вот мы и подошли к самому главному – будем отправлять всё, что получилось, на хостинг heroku.

Для этого есть два способа:

1. Залить проект в репозиторий heroku, и он уже сам добавит нужные настройки
2. Залить на github и в настройках heroku указать ссылку

Мы пойдем по второму пути.

Надеюсь, рассказывать, как заливать проект на github, не нужно?
Я залил сюда.

Если вам всё же интересно почитать про первый способ, вот ссылка. Он особо ничем не отличается, разве что тем, что код будет храниться на стороне heroku.

Возможно, у вас нет аккаунта на github, и этот способ окажется даже проще. Пробуйте.

Настройка хостинга

Когда залили проект на github, переходим в дашборду heroku , чтобы создать новый проект.

На этой странице будут находиться все ваши проекты. Чтобы создать новый, сверху справа нажмите на кнопку New, далее на Create new app. Откроется новая страница, на которой нужно ввести данные о новом проекте.

После завершения проект будет создан и нас перенаправит во вкладку Deploy. Там сразу перейдем в настройки github

Находим нужный нам репозиторий и коннектим

Далее выберем ветку, за которой будет наблюдать heroku, и нажмём на большую тёмную кнопку.

Теперь, когда вы зальёте что-то в ветку master, heroku будет подтягивать изменения и обновлять сайт.

На данный момент heroku не успел еще ничего стянуть, поэтому воспользуемся кнопкой ручного обновления

После того как сборка завершится (процесс можно отслеживать во вкладке Activity), нажимаем на кнопку Open app

Откроется новая вкладка, и мы снова увидим стартовую страницу нашего сайта, но уже на хостинге heroku. Сайт готов к продакшну, осталось только купить домен. Купить можно тут.
Поменять во вкладке Settings, в секции Domains

В этой же вкладке вы можете настраивать env переменные, устанавливать различные плагины и т.д. Советую изучить все вкладки, чтобы иметь полное представление о возможностях этого хостинга.

Я считаю, что цель статьи была выполнена и можно заканчивать. По всем остальным вопросам обращайтесь в официальную документацию.

Пайплайны в разработке

Пайплайн (от англ. pipeline — трубопровод) — это последовательность действий или процессов, которые выполняются для достижения заданной цели. Такой метод управления проектом состоит из этапов, на каждом из которых выполняется определенная задача или набор задач. Каждый этап имеет свои входные и выходные данные, условия запуска и завершения, зависимости от других этапов. Пайплайны бывают разными по сложности и длительности, в зависимости от типа и масштаба проекта, используемых технологий и инструментов, требований к качеству и безопасности продукта.

Общая цель пайплайна в программировании — автоматизировать, ускорить и упростить процесс разработки, повысить ее надежность и прозрачность, снизить риски ошибок и сбоев.

Основные характеристики

• Непрерывность процесса. Пайплайн обеспечивает потоковый характер работы — сотрудники последовательно выполняют свои задачи, передавая результат друг другу. Это повышает скорость и эффективность разработки.
• Гибкость. Пайплайн легко адаптируется к изменениям — новые задачи добавляются в общий конвейер работ. Это помогает оперативно реагировать на меняющиеся требования.
• Контроль качества. На каждой стадии происходит проверка результатов предыдущего этапа. Это позволяет сразу выявлять и устранять ошибки, не допуская их накопления.
• Масштабируемость. Пайплайн одинаково эффективен как для небольших, так и для крупных проектов с участием многих команд. Его легко масштабировать при росте задач.
• Широкие возможности мониторинга. Они появляются за счет отслеживания прогресса каждого этапа разработки по конкретным метрикам. Это облегчает анализ эффективности процесса.

Сферы применения

Кроме бизнес-задач, пайплайны широко используются в различных сферах IT, включая обработку данных и Data Science, при машинном обучении и при создании искусственного интеллекта, в сетевой инфраструктуре, а также в Gamedev, DevOps, разработке ПО и веб-сайтов. Подробнее мы рассмотрим только последние 4 пункта.

DevOps

DevOps — это методология разработки программного обеспечения, которая объединяет процессы разработки (Dev) и эксплуатации (Ops) в единую цепочку. Цель DevOps — обеспечить непрерывную поставку (Continuous Delivery) качественного и безопасного продукта с минимальными затратами времени и ресурсов.

1. Планирование: определяются требования к продукту, его функциональность и архитектура. Затем формируются задачи для команды разработчиков и определяются сроки и приоритеты.
2. Кодирование: написание кода для продукта с использованием различных языков программирования и инструментов. На этом этапе осуществляется контроль версий кода с помощью систем управления версиями (например, Git).
3. Сборка: компиляция кода в исполняемый формат (.exe или .apk) с помощью инструментов сборки (Maven или Gradle). Далее код проходит проверку качества с помощью инструментов анализа.

Разработка ПО

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

Пайплайны для разработки ПО могут быть разными в зависимости от типа и масштаба проекта, используемых языков программирования и фреймворков, методологий разработки. Но существуют и общие принципы:

• Непрерывная интеграция (Continuous Integration, CI) — это процесс постоянного слияния кода из разных источников в единую базу кода и его проверки на ошибки и несоответствия стандартам. Цель CI — обеспечить консистентность и качество кода, а также уменьшить конфликты при слиянии кода.
• Непрерывная доставка (Continuous Delivery, CD) — процесс постоянного готовности кода к развертыванию в целевой среде. Задача CD — обеспечить быстрое и безопасное доставление кода до конечных пользователей или клиентов.
• Непрерывное тестирование (Continuous Testing, CT) — постоянное тестирование кода на разных уровнях: модульном, интеграционном, функциональном и нагрузочном. Цель CT — обеспечить работоспособность и соответствие требованиям кода, а также выявить и исправить ошибки на ранних стадиях разработки.
• Непрерывный мониторинг (Continuous Monitoring, CM) — отслеживание состояния и производительности кода в целевой среде. На этом этапе обеспечивается стабильность и безопасность кода, а также собирается обратная связь от пользователей или клиентов.
• Системы контроля версий (например, Git)
• Серверы непрерывной интеграции и доставки (Jenkins)
• Среды разработки (Visual Studio Code)
• Фреймворки или платформы для разработки (Spring Boot)
• Библиотеки или плагины для упрощения решения определенных задач или добавления дополнительной функциональности (Lombok)
• Инструменты для тестирования (JUnit), развертывания (Docker) и мониторинга (Prometheus).

Веб-сайты и приложения

Веб-сайты и приложения — это программные продукты, которые работают в интернете и предоставляют пользователям различные сервисы. Они требуют разработки как на стороне сервера, так и на стороне клиента, однако они имеют такие же принципы построения пайплайнов, как и при разработке программного обеспечения.

• Системы контроля версий
• Серверы непрерывной интеграции и доставки
• Среды разработки
• Фреймворки или платформы для разработки (например, React или Angular для фронтенда, Node.js или Django для бэкенда)
• Библиотеки или плагины для упрощения решения определенных задач или добавления дополнительной функциональности (Bootstrap или Material UI для дизайна интерфейса)
• Для тестирования (Jest или Selenium), развертывания (Docker или Heroku) и мониторинга (Google Analytics или New Relic).

Gamedev

Игры — это сложные и многофункциональные программные продукты, которые требуют большого объема ресурсов, таких как графика, звук, анимация, физика и логика. Чтобы игра прошла путь от идеи до релиза успешно — необходимо использовать пайплайн-подход.

Пример пайплайна для Gamedev на Unity

Для того, чтобы показать, как выглядит пайплайн для Gamedev на практике, давайте рассмотрим пример одного из популярных игровых движков — Unity. Unity — это кроссплатформенный движок для разработки игр для разных устройств и платформ, таких как ПК, мобильные телефоны, консоли, VR и AR. Unity предоставляет разработчикам инструменты и ресурсы для создания игр, например: графический редактор, физический движок, анимационная система, звуковая система и скриптовый язык C#.

1. Препродакшн: определяется концепция игры, ее жанр, сюжет, персонажи, локации, механики и создаются дизайн-документы, прототипы и референсы для игры.
2. Продакшн: идет процесс производства игры, то есть создание всех необходимых ресурсов: моделей, текстур, звуков и скриптов. Также на этом этапе проходит тестирование и отладка игры на разных платформах и устройствах.
3. Постпродакшн: добавляются финальные штрихи, исправляются ошибки, делается оптимизация производительности и дальше на этом этапе подключается маркетинг, продвижение игры, а также сбор обратной связи от пользователей.

• Система контроля версий (VCS) позволяет хранить, отслеживать и совместно использовать исходный код и ресурсы игры (Git или Perforce).
• Сервер непрерывной интеграции и доставки (CI/CD) для автоматизирования процесса сборки, тестирования и развертывания игры (Jenkins или Unity Cloud Build).
• Среда разработки (IDE) предоставляет удобный интерфейс для написания, отладки и запуска кода игры. Например, Visual Studio или Visual Studio Code.
• Фреймворк или платформа для разработки игры выбирается в соответствии с выбранным жанром и стилем (Unity или Unreal Engine).
• Библиотеки/плагины для упрощения решения определенных задач или добавления дополнительной функциональности к игре (Cinemachine или ProBuilder для Unity).
• Инструменты для тестирования игры на разных уровнях: модульном, интеграционном, функциональном и нагрузочном (NUnit или Unity Test Framework для Unity).
• Инструментарий для развертывания игры в целевой среде: локальной, тестовой или продуктовой (Steam или Google Play для публикации игры).
• Инструменты для мониторинга работы игры в целевой среде: отслеживание состояния, производительности и ошибок (Unity Analytics или Firebase для аналитики игры).

Контроль выполнения

Для того, чтобы обеспечить эффективность и надежность пайплайнов, необходимо контролировать их выполнение на разных этапах. Для этого нужно следить за:

• Статусом выполнения пайплайна. То есть в каком состоянии находится пайплайн в данный момент: запущен, остановлен, завершен или имеет ошибки. Мониторинг статуса помогает вовремя идентифицировать проблемы в работе пайплайна и подскажет какие действия нужно предпринять для их устранения.
• Прогрессом выполнения пайплайна. Нужно отслеживать сколько времени занимает выполнение каждого этапа и какова его общая длительность. Прогресс помогает оценить, насколько быстро и эффективно работает пайплайн и какие факторы влияют на его скорость и производительность.
• Результатами выполнения пайплайна. Проверка на соответствие данных ожиданиям и требованиям также помогает вовремя выявить и исправить ошибки или несоответствия в данных.
• Логами выполнения пайплайна. Логи выполнения пайплайна помогают отслеживать и анализировать ход работы пайплайна, а также выявлять и решать проблемы.

Преимущества перед традиционными методами разработки

Давайте сначала обозначим, что мы понимаем под традиционными методами обработки — старые и морально устаревшие методы (но, к сожалению, еще использующиеся), которые имеют общие черты:

• Ручная сборка и развертывание: разработчики выполняют все операции сборки и развертывания вручную, включая скачивание зависимостей, компиляцию программного кода и копирование файлов на необходимые серверы.
• Монолитное развертывание: развертывание целого приложения целиком без декомпозиции на более мелкие части. При обновлении или добавлении новой функциональности в приложение требуется его полное перестроение, что займет много времени и затруднит обслуживание и масштабирование приложения.
• Отсутствие автоматизированных тестов: разработчикам приходится тратить больше времени на ручное тестирование и отладку кода, что может замедлить процесс разработки и повысить риск ошибок.
• Неэффективное управление зависимостями: в традиционных методах разработки затруднительно управление зависимостями между компонентами, библиотеками и другими ресурсами. Разработчики постоянно сталкиваются с проблемами несовместимости версий, конфликтами зависимостей и неэффективным использованием ресурсов.

• Повышение производительности и эффективности работы команды разработчиков. Это происходит за счет автоматизирования рутинных и повторяющихся задач и приводит к сокращению времени на их выполнение, а также устраняет ошибки «человеческого фактора» при ручном запуске операций.
• Улучшение качества и безопасности продукта. Пайплайны обеспечивают постоянный контроль за состоянием кода, его соответствием стандартам и требованиям, а также регулярное тестирование на разных уровнях. Такой подход помогает выявлять и исправлять ошибки на ранних стадиях разработки, а также предотвращать утечку или потерю данных.
• Ускорение доставки продукта до конечных пользователей. Пайплайны позволяют быстро и безболезненно переносить код из одной среды в другую, например, из локальной в тестовую или из тестовой в продуктовую. Также они облегчают процесс обновления продукта, добавления новых функций или исправления ошибок.
• Увеличение удовлетворенности клиентов и пользователей. Когда создается качественный, безопасный продукт с быстрой и стабильной доставкой, то автоматически повышается уровень доверия и лояльности целевой аудитории, а также их удовлетворенность от использования продукта.

Heroku

Heroku — облачная мультиязычная платформа как услуга (PaaS), основанная на управляемой контейнерной системе, с интегрированными службами передачи данных и развитой экосистемой для развертывания и запуска приложений.

«IT-специалист с нуля» наш лучший курс для старта в IT

Для чего нужна платформа Heroku

Обычно приложения работают на выделенном сервере, а для сайтов используют хостинги. Но возможности хостингов ограничены. А выделенные серверы, такие как VPS, нужно настраивать: самостоятельно определять архитектуру, собирать приложение, заботиться о безопасности. Тратить на это ресурсы не всегда возможно.

В таких случаях используется Heroku. Платформа позволяет загружать любое приложение и не заниматься настройкой серверной части.

Heroku — Platform as a Service. Это означает, что платформа работает как сервис: предоставляет пользователю определенные функции и возможности, доступ к системам и ПО. При этом ее инфраструктура полностью скрыта.

За пользователя все делают сотрудники сервиса — эта работа остается «под капотом», а многие процессы автоматизированы. За безопасность, архитектуру и настройку сервера отвечают специалисты платформы.

Поэтому Heroku нужна:

• для размещения приложений и веб-сервисов;
• упрощения и ускорения цикла разработки;
• снижения потребности в сложной работе с сервером;
• работы с нагруженными приложениями;
• быстрого масштабирования проектов.

Есть нюанс. На цену влияет количество ресурсов, которые использует клиент. Поэтому Heroku не всегда подходит для хайлоад-проектов: обеспечивать работу сервера может быть дешевле, чем использовать платформу.

Профессия / 8 месяцев
IT-специалист с нуля

Попробуйте 9 профессий за 2 месяца и выберите подходящую вам

Как работает Heroku

Диносы. Работающие в Heroku приложения выполняются изолированно от других — они заключены в специальные контейнеры, которые называются диносами или дино (dyno, dynos). Диносы позволяют создать легковесную независимую среду и развернуть в ней приложение так, чтобы настройки его среды не конфликтовали с другими. Одно приложение может использоваться несколькими диносами, и проект легко масштабируется под задачи разработчика.

Типы процессов. У диносов есть шаблоны — прототипы, на основе которых создается контейнер, как деталь по чертежу. Именно благодаря им приложения в Heroku легко масштабировать.

• Каждый тип процесса отвечает за свою часть работы и не затрагивает другие модули. Это помогает параллелизму: процессы разделяются и задачи не смешиваются. Так можно избежать конфликтов.
• Диносы легко масштабировать. Если программа потребует больше ресурсов, увеличить рабочие мощности можно в несколько кликов. Для этого нужно добавить необходимое количество новых диносов с такими же типами процессов, как в используемых до того.

Курс для новичков «IT-специалист
с нуля» – разберемся, какая профессия вам подходит, и поможем вам ее освоить

Как пользоваться платформой

1. Зарегистрироваться на официальном сайте Heroku и выбрать тариф. Для начинающих подойдет стартовый Free: дорогостоящие тарифы нужны для высоконагруженных приложений и коммерческого использования.
2. Скачать официальную консольную утилиту The Heroku Command Line Interface (CLI, также известна как Herokuapp) на сайте сервиса. Для ее работы необходим установленный Git.
3. Открыть приложение в командной строке, написать команду heroku login -i, а затем ввести данные от своего аккаунта. Запуск команды без -i откроет браузер. Войти в аккаунт можно и через него.
4. Перейти в папку, где хранится приложение, и ввести команду heroku create. Heroku автоматически обработает приложение.

Особенности Heroku

Мультиязычность. Heroku поддерживает Ruby, Python, PHP, Node.js, Java, Go, Scala и Clojure. Изначально платформа создавалась для работы с Ruby on Rails, поэтому в старой документации часто встречается упоминание этой связки. Сама платформа Heroku работает на Debian и Ubuntu, дистрибутивах Linux.

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

Дополнительные возможности. Среди проектов Heroku — собственная СУБД SQL database as a service, программное обеспечение для связи команды разработчиков между собой, сервисы автоматизации для программ на разных языках и многое другое. Платформа работает и с noSQL-решениями. Инструментами можно пользоваться вместе с основным облачным сервисом.

Интеграция с сервисами. Heroku «из коробки» поддерживает Docker и Git. Они доступны даже в базовых тарифах. Если программисту не хватает встроенных возможностей и собственных проектов Heroku, он может воспользоваться надстройками — дополнительными модулями, которые открывают доступ к стороннему ПО.

Бесплатный доступ для небольших проектов. В Heroku есть начальный тариф Free. Он бесплатно дает пользователю 550–1000 часов работы диносов в месяц. В тарифе доступны два типа процессов и возможность добавлять пользовательские домены. Через 30 минут без активности сервис «засыпает»: этого можно избежать при выборе другого базового тарифа.

Подробная документация. На сайте Heroku Dev Center доступны пошаговые руководства и туториалы. В них подробно описаны особенности работы с Heroku для приложений на всех поддерживаемых языках. Официальная документация доступна на английском и японском.

IT-специалист с нуля

Наш лучший курс для старта в IT. За 2 месяца вы пробуете себя в девяти разных профессиях: мобильной и веб-разработке, тестировании, аналитике и даже Data Science — выберите подходящую и сразу освойте ее.

Pipelines

A pipeline is a group of Heroku apps that share the same codebase. Each app in a pipeline represents one of the following stages in a continuous delivery workflow:

• Development
• Review
• Staging
• Production

Pipelines are extremely useful for managing multiple environments for your app. A common pipeline workflow has the following steps:

1. A developer creates a pull request to make a change to the codebase.
2. Heroku automatically creates a review app for the pull request, allowing developers to test the change.
3. When the change is ready, it’s merged into the codebase’s master branch.
4. The master branch is automatically deployed to the pipeline’s staging app for further testing.
5. When the change is ready, a developer promotes the staging app to production, making it available to the app’s end users.

A pipeline’s overview page illustrates the stages of this flow and provides meta-information about the status of each stage. For example, you can see if your production app is running different code than staging.

Creating pipelines

From the Heroku Dashboard

Click the New button in the top right of your app list and select Create new pipeline :

Alternatively, you can navigate to an app’s Deploy tab and create a new pipeline to include that app.

From the Heroku CLI

You can use the pipelines:create command to create a pipeline from the CLI. Note that the command must specify an existing app that you want to add to the pipeline.

$ heroku pipelines:create -a example-app ? Pipeline name: example-pipeline ? Stage of example-app: production Creating example-pipeline pipeline. done Adding example-app to example-pipeline pipeline as production. done 

The CLI prompts you to specify a name for the pipeline and a stage for the app you’re adding to it ( development , staging , or production ).

Use heroku help pipelines:create to see a full list of options for this command.

Accessing pipelines

Apps in a pipeline do not appear as individual apps in the Heroku Dashboard. Instead, they appear as part of a single pipeline entry with a drop-down to view individual apps:

Adding apps to a pipeline

A Heroku app can belong to exactly one stage of exactly one pipeline.

From the Heroku Dashboard

From your pipeline’s overview page, click + Add app next to a deployment stage to add an existing application to that stage of the pipeline.

From the Heroku CLI

Add an app to your pipeline with the heroku pipelines:add command:

$ heroku pipelines:add example-pipeline -a example-staging-app ? Stage of example-staging: staging Adding example-staging to example pipeline as staging. done 

Multiple apps in a pipeline stage

Pipeline stages can include more than one app. For example, the production stage might have the main production app and an admin app running the same version of code, but with different configurations.

Deployment with pipelines

Pipelines let you define how your deployed code flows from one environment to the next. For example, you can deploy code to your staging app (which builds it into a slug) and later promote that same slug to production. This promotion flow ensures that production contains the exact same code that you tested in staging, and it’s also much faster than rebuilding the slug.

Promoting

After you’ve fully tested a change in a particular pipeline stage, you can promote its associated slug to the app(s) in the downstream stage.

Downstream refers to the next environment stage in a pipeline. For example, given a development —> staging —> production pipeline, staging is downstream of development, and production is downstream of staging.

From the Heroku Dashboard

You promote a particular stage’s slug by clicking its associated Promote button on your pipeline’s overview page:

If there are multiple apps in the downstream stage, you can specify which ones you want to promote the slug to.

The Promote button will only be available if there are apps in the subsequent stage(s). In other words, if staging has an app to be promoted to production but the production stage doesn’t contain any apps, there will be nothing in which to promote the staging app, and thus no promotion target.

From the Heroku CLI

From the CLI, you can promote a slug with the heroku pipelines:promote command. The command must specify the name ( -a ) or Git remote ( -r ) of the source app:

$ heroku pipelines:promote -r staging Promoting example-staging to example (production). done, v23 Promoting example-staging to example-admin (production). done, v54 

By default, this command promotes the source app’s slug to all apps in the downstream stage. You can specify a subset of these apps to promote to with the —to option:

$ heroku pipelines:promote -r staging --to my-production-app1,my-production-app2 Starting promotion to apps: my-production-app1,my-production-app2. done Waiting for promotion to complete. done Promotion successful my-production-app1: succeeded my-production-app2: succeeded 

Release phase during a promotion

Release Phase does run when you promote a slug, despite the fact that no new build is created.

Pipelines ownership and transfer

The Pipelines web interface and CLI encourage and require that apps in a Pipeline be owned by the Pipeline owner. This owner can be assigned in the Settings tab of the Pipelines web interface.

Electing to assign a Pipeline owner, typically a Heroku Team, will prevent common permissions-related issues in collaborative workflows. This is especially important when owners wish to assign team members differing access to production, staging, and development apps.

This feature encourages better structure and administrative hierarchy in Pipelines.

A user is eligible to own a Pipeline if the user owns app(s) in a Pipeline. Once a user assumes ownership of the Pipeline, the web UI will highlight Pipeline apps not owned by that user and provide a UI to transfer the foreign apps in the Pipeline to the Pipeline owner.

Pipelines owned by an individual can only be transferred to a Heroku Team (or Enterprise Team) in which that individual are an member. Team-owned Pipelines can be transferred to any individual that is a member of that Team. However, for billing security, individual Pipelines cannot be transferred directly to other individuals.

GitHub Sync

Promoting from staging to production is great, but you can further optimize your flow by automatically deploying to staging using GitHub integration. For example, whenever the master branch is updated on GitHub and continuous integration (CI) tests pass, staging can be auto-deployed.

Review apps

If you’re using GitHub, we highly recommend using pull requests and setting up corresponding review apps. Dynos and add-ons used by review apps are charged in exactly the same way as for normal apps. See Review App Management and Costs for more info.

Pipelines and Heroku CI

If you’re using GitHub, you can turn on Heroku CI, Heroku’s visual, low-configuration Test Runner that integrates easily with Heroku Pipelines. Any Heroku Pipeline is already CI-ready–just turn it on in the pipeline’s Settings tab. Dyno and add-on run time for the duration of the test run is charged at the normal rate prorated to the second.

Ephemeral app permissions

Review apps and CI apps are short-lived, “ephemeral” apps. You can set user permissions and manage access to all ephemeral apps within a pipeline via the pipeline’s access tab. The access tab is available to “admin” users in Heroku Teams and Enterprise Teams, and to pipeline owners in personal accounts.

Permissions in the pipeline access tab are only applied to review apps and CI apps.

With the new version of Review Apps, all users with “member” role in the Enterprise Teams and Heroku Teams were automatically added to Review Apps via auto-join with “View”, “Operate” and “Deploy” permissions. The pipelines access tab makes it possible to manage and modify auto-join access. Modifying auto-join permissions are only possible for Enterprise Teams. For Heroku Teams, the “View”, “Operate” and “Deploy” permissions that “members” get via auto-join are static and can’t change.

To edit permission for existing pipelines in an Enterprise Team, select the small pencil icon in the “Default permissions for new team members” section of the pipeline access tab. You can also disable auto-join completely. Permission changes and turning off/on auto-join will only be effective for new apps and doesn’t change previous settings.

Auto-join is when users with “member” role in the Enterprise Team and Heroku Teams are automatically added to the pipeline with “View”, “Operate” and “Deploy” permissions on Review Apps and CI Apps. Via the pipeline access tab, you can disable auto-join, or modify auto-join permissions for Enterprise Team “members”. For Heroku Teams, permissions are static and can’t change.

Any changes to user permissions in the pipeline access tab, turning on and off auto-join, and editing exiting auto-join permissions will only be applied to new apps from the time you make those changes. They won’t be applied to existing apps.

For new pipelines, the default is set to auto-join enabled with “View”, “Operate” and “Deploy” permissions selected. You can turn auto-join off or modify permissions when creating the pipeline.

For all other users that are not added automatically via auto-join, you can add them manually. As an example, if you want a “collaborator” user to have “operate” access to the Review Apps and CI Apps within the pipeline, add the user manually under the pipeline access tab with “operate” permission selected.

For Heroku Teams, permissions are static and can’t be modified, so there are no options to select permissions when enabling auto-join:

And no options to edit existing user permissions. User’s get pre-set static permissions based on their role in the team:

For personal accounts there is no concept of auto-join since there is no higher team layer, but each pipeline has the access tab via which you can add users that you want to have access to Review Apps and CI Apps within the pipeline:

Permissions and capabilities

While pipeline level permissions look the same as Heroku app permissions, their capabilities are different and specific to actions users can take on Review Apps and CI Apps.

Only users with “admin” role in Enterprise Teams and Online Teams, and pipeline owners in personal account can access and modify pipeline level permissions.

Action	View	Deploy	Operate	Manage
Review Apps
View pull requests	X	X	X	X
View Review Apps	X	X	X	X
Open Review Apps	X	X	X	X
Create Review Apps	X	X	X	X
Delete Review Apps	X	X	X	X
See build information	X	X	X
Edit config vars	X	X	X
CI
View tests	X	X	X	X
Create CI apps	X	X
Enable CI	X
Cancel CI runs	X

Design considerations

Pipelines manage the flow of application slugs only. Your app’s Git repo, config vars, add-ons, and other environmental dependencies must be managed independently.

Deploying via pipeline promotion is recommended only for apps with stateless builds. Builds that compile configuration variable values into the slug (i.e., stateful builds) can encounter issues when promoted. For apps with stateful builds, use Heroku’s standard Git-based deployment or GitHub deploys instead.

When a slug is promoted, Heroku copies it without making any changes. It is not rebuilt for the environment of the target app. If your builds bake in environment from the build-app context, then your slugs are not portable between pipeline stages. This may be the case, for example, if you’re using Ruby on Rails and the asset pipeline to build assets hosted at a CDN defined by a URL in your build environment. This is because URLs specific to the build-app will be baked into css and js-files, and those will not work correctly when promoted. Please see this article for instructions on how to configure this with Rails.

Slugs are associated with the stack on which they were built, since they typically contain binaries compiled against the system libraries in that stack. As such, promoting a slug from one app to another will update the stack of the target app to match that of the originating app.

FAQ

What else can I do with the pipelines CLI?

A complete list of Pipelines commands with usage details is available in the console:

$ heroku help pipelines 

The repository README for the Heroku CLI plugin provides additional usage examples and a feature history.

Can I have pipelines stages other than development, staging and production?

No, only those three stages are currently supported, plus the special stage, review.

Can I run scripts, such as rake db:migrate when promoting?

Heroku Release Phase lets you perform common tasks like schema migrations before a new version of your app is deployed to any step of the continuous delivery flow. See its documentation for more information.

Can I have more than one app in a pipeline stage?

Do pipelines always require a app?

Yes, pipelines require to always contain one application. Pipelines that do not contain any apps are not accessible via our dashboard and will be scheduled to be deleted. It is highly recommended you have at least one permanent app in your pipeline as you cannot always guarantee that a review app will exist within the pipeline.

Do pipelines work without GitHub?

Yes. Pipelines are very well integrated with GitHub, but this integration is not required.

I don’t see a “development” stage, how do I add a development app?

You can add the app to any other stage, and then using the context menu on the app card, move the app to “development”. Alternatively, you can go to the Deploy tab of the app and add it to a pipeline from there, while specifying the “development” stage.

Do Pipelines work with Heroku Enterprise Teams?

Yes, Pipelines are fully supported for Enterprise Teams. However, in some cases team members may find they cannot operate on a given app in a pipeline due to the access control, such as that described in Using App Permissions in Heroku Enterprise Teams. Users must have adequate permissions to perform the relevant operations on the app.

Do Pipelines work with Private Spaces?

Yes, a Pipeline can span apps in the Common Runtime and in multiple different Private Spaces. This allows you to have test and staging apps in the Common Runtime or in a separate Private Space while promoting to a Private Space with only production apps.

How much do Pipelines cost?

While the use of the Pipelines feature itself is free, you still incur costs for any dynos or add-ons used by your apps in the pipeline.

Keep reading