pipeline heroku что это

Understanding Heroku Pipelines

For years Heroku has been the choice platform for developers looking to host their web applications. With just a new pushed commit, the Heroku Platform handles everything from deployment and scaling to integrating with ecosystem partners.

In larger teams and those with complex projects, it’s not enough to just deploy on each new commit. A new, more methodical workflow is needed to ensure developers have the latest version of a codebase and only the latest stable version is available to users. Fortunately, the rise of Continuous Integration / Continuous Delivery (CI/CD) answers this need.

Continuous Integration is part of the Heroku Flow and is tightly linked with Heroku Pipelines and Review Apps. In this post, we’ll introduce you to these concepts and tools in the context of working in a team.

Gitting Good

It wouldn’t be right to cover the Heroku Flow without first taking a whirlwind tour of the way many teams use Git and GitHub to manage their codebases.

While using Git, we create snapshots (commits) of their code. At any point we can take t, e latest commit and create a parallel version of it (a branch) to build new features without impacting the stable (master) branch.

Once we’re happy with their code and want to incorporate it back into master, they create a ‘pull request’ where code is reviewed and then ‘merged’. The master branch now has the changes incorporated.

Unlike some other providers, Heroku Pipelines make this a breeze to set up and use with little-to-no setup time to get started and sensible user permissions out of the box.

Setting up a Pipeline

You can set up a Pipeline by clicking ‘Create New Pipeline’ (who’d have thought?) and connecting it to a GitHub repository.

At its most basic you’ve just set up a working Pipeline. But there are several more features just a few clicks away that turn your new Heroku Pipeline into an incredibly powerful review tool:

With everything set up, let’s run through how you can now use your souped-up Pipeline to its fullest.

Let’s get our work reviewed

Let’s assume you’ve created a branch and are working on a new feature of your application. You’re ready to get feedback and hopefully push your code to production. The first step will always be to create a pull request on GitHub.

Previously, you or a team member might have simply merged the work into the master branch blind, or had to download that PR’s worth of work and get it running in order to review it.

Now, with the Heroku Flow, and the enabled settings in our Pipeline, two things will happen:

As this Pipeline is part of Heroku Teams you can request a review from another member who will have access to both the test requests and the review app. All from five minutes of setup. Magic.

When the PR is merged the review app is automatically destroyed as it’s no longer needed. As the repository now has a new commit in master as a result of the merge, the Heroku app is also moved to the staging phase.

Isn’t it live yet?

You might be itching to get your app live to production, but the app is moved to staging and not to production. While this may immediately feel like an extra step if you’ve not used a staging environment before, there are some benefits to having one.

Unlike the step between review and staging, the step between staging and production also allows for what we call ‘release phase tasks’. These are scripts that can perform operations as your site is deployed and often includes things like minifying assets, uploading content to content delivery networks or invalidating caches.

When you’re ready, you can ‘Promote’ the staging application to production, which will then be made available to your users with no downtime. Your production environment will then mirror your staging environment until you merge new PRs into master.

What just happened?

Without the need to configure roles or read lengthy documentation we’ve taken an existing application and created a CI/CD workflow. When new PRs are created we automatically have a testing URL for reviewers and a summary of our automated tests.

By default the static permissions in Heroku Teams only Admins can promote apps to production, but you might consider fine-tuning the permissions if you have Heroku Enterprise.

We hope that you feel ready to set up your first Heroku Pipeline. Once you’ve set up a couple, you might consider learning about how to get the most from Heroku CI.

Источник

Categories

Last updated January 21, 2021

Table of Contents

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:

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

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.

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:

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.

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

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 will eventually 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.

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.

Ephemeral app permissions

The pipeline access tab can only be used to manage Review Apps access for users of the new Review Apps. If you are using the older version of Review Apps please upgrade to the new version to use this feature. If you have CI enabled, the pipeline access tab can be used to manage user permissions on CI apps whether you are using the new version of Review Apps or the old version.

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.

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.

What else can I do with the pipelines CLI?

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

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.

Источник

Развертывание приложений Django в Heroku с GitHub

В этой статье мы расскажем о развертывании приложения Django в конвейере Heroku из репозитория GitHub.

Развертывание приложений Django в Heroku с GitHub

Вступление

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

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

Предпосылки

Для этого поста нам понадобится:

Демонстрационное Приложение

Загрузка приложения Django

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

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

На данный момент структура папок нашего проекта выглядит следующим образом:

Прежде чем мы развернемся на Heroku, нам нужно будет внести некоторые изменения. Во-первых, нам нужно изменить настройку ALLOWED_HOSTS в нашем plaindjango/settings.py к:

Следующее изменение, которое нам нужно сделать, – это указать папку для наших статических файлов с помощью параметра STATIC_ROOT :

Подготовка приложения к развертыванию

Когда наше приложение Django готово, Heroku требует, чтобы мы включили следующие файлы в корень нашего проекта, чтобы он был готов к развертыванию:

Цель этого файла-указать версию Python, которая будет использоваться для запуска нашего проекта. В нашем случае файл будет просто содержать:

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

При настройке мы установили Gunicorn (‘Green Unicorn’), который является чистым Python WSGI (Web Server Gateway Interface) сервером для UNIX.

В то время как Django поставляется со своим собственным сервером WSGI, наш профиль скажет Heroku использовать Gunicorn для обслуживания нашего приложения. Содержимое этого файла будет:

Наконец, нам нужен requirements.txt файл, определяющий требования нашего приложения Django. Мы можем создать это в нашей виртуальной среде, выполнив следующую команду:

Окончательная структура папок нашего приложения Django, содержащая дополнительные файлы, теперь будет:

С этими файлами на месте наше приложение готово к Heroku.

Развертывание в Heroku через GitHub

Хотя Heroku предлагает свою собственную платформу Git, которую мы можем использовать для наших развертываний, она не так богата функциями, как GitHub. Heroku также позволяет нам извлекать наш код из GitHub и развертывать его.

Наш код готов к развертыванию, поэтому мы можем пойти дальше и создать репозиторий GitHub и продвинуть наш код.

Когда наша работа будет готова на GitHub, давайте перейдем к Heroku и создадим новый конвейер, используя кнопку “Новый” в правом верхнем углу панели управления Heroku.

Мы предоставляем имя нашего конвейера и репозитория GitHub для подключения:

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

Это означает, что через Heroku мы можем развернуть наш код в нашей производственной, промежуточной и среде разработки одновременно, все из GitHub.

При использовании GitHub в качестве источника нашего приложения мы можем настроить конвейеры Heroku для развертывания кода из разных ветвей в разные среды.

Например, код в нашей ветви “master” будет развернут в производственной среде, ветвь “staging” – в нашей промежуточной среде, а ветвь “dev” – в нашей среде разработки.

Это дает нам видимость нашего проекта на нескольких этапах, улучшая нашу доставку.

Конвейеры Heroku имеют функцию под названием “Review Apps”, которая позволяет нам развертывать Pull Requests как автономные приложения. Если это включено, мы можем проверить работу в запросах на вытягивание без необходимости извлекать изменения локально и тестировать их.

Трубопровод Heroku

Это вид нашего недавно созданного конвейера для нашего приложения на GitHub:

Конвейер по умолчанию состоит из двух этапов и раздела, позволяющего просматривать приложения. Поскольку весь наш код в настоящее время находится в ветке “master”, давайте продолжим и развернем ветку, нажав на кнопку “Добавить приложение” на этапе производства:

Наше рабочее приложение было создано, но наш код еще не запущен. Следующим шагом является выбор ветви, из которой код будет развернут в нашей производственной среде:

Как только мы нажмем на кнопку “Развернуть”, Heroku вытащит наш код из ветви “мастер” и развернет его. Мы можем просмотреть ход развертывания, просмотрев журналы, и как только приложение будет развернуто, мы получим ссылку на наше запущенное приложение:

В самом конце журналов есть ссылка на наше запущенное приложение. Когда мы переходим по ссылке, нас приветствует наша целевая страница Django:

Мы успешно развернули наше производственное приложение Django в Heroku через GitHub. Чтобы создать приложение для нашей промежуточной среды, выполняются те же шаги, что и для основной среды.

Мы начнем с создания “промежуточной” ветки на GitHub через терминал:

Наконец, в проект добавляется приложение и создается запрос на вытягивание из ветви “staging” в ветвь “master”.

Мы видим, что для нашего запроса на вытягивание было создано новое приложение, и когда мы открываем его, мы видим изменения, которые запрос на вытягивание вносит в наш проект:

Наш запрос на вытягивание был успешно развернут, и мы можем просмотреть его перед объединением изменений в master. При активированном автоматическом развертывании Heroku развернет наши изменения, как только мы объединим запрос на вытягивание в главную ветвь, и изменения будут запущены автоматически.

Вывод

Наше приложение Django было развернуто в Heroku из GitHub с помощью конвейера. Хотя это не единственный способ развертывания приложения Django в Heroku, он наиболее подходит для совместного проекта.

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

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

С приложениями Django на Heroku можно добиться большего, и этот пост должен был представить простой взгляд на то, как развернуть приложение Django на платформе таким образом, чтобы оно соответствовало нашему ежедневному рабочему процессу.

Источник