Intro Links

What Is Hephy Workflow

https://docs.teamhephy.com/managing-workflow/security-considerations/
https://docs.teamhephy.com/contributing/submitting-a-pull-request/

Hephy Workflow maintains support for Heroku Buildpacks:

Buildpacks

When using buildpacks, developers options are constrained by the list of available languages and prescribed workflow (which is quite a nice selection to begin with, frankly, that can also be expanded upon by writing custom buildpacks.)

Many developers never would need to stray beyond a Buildpack-style deployment on one of the built-in languages, but we can also compile our own buildpacks, and for production this model may have some troubling characteristics.

Dockerfiles

Perhaps buildpacks are unacceptable, and one prefers to build the environment to suit, in this case one has chosen to use a Dockerfile with an upstream base image that is meant to be refreshed periodically with patches as they arrive.

Kingdon's Example App for Hephy/Deis Workflow:

The "simplest-commitbee" app demonstrates rvm-driven support for adding multiple Ruby versions unobtrusively in a standard Dockerfile-based image build workflow.

Deployments (Procfile)

The installation and maintenance mechanism is open to your own option1 because of the choice to use Dockerfile, but the combination of Dockerfile and Procfile is extremely powerful in Hephy Workflow for managing deployment of several concurrent processes, like in the example which shows a frontend service and some background workers.

Without Workflow, when using a Dockerfile, it's incumbent on the operator to specify an ENTRYPOINT, or CMD at image build time, and each image can only build in one command; if multiple commands are needed, one could define the Kubernetes pod specs with several containers pointing at the same (or different) images, each having a command to run via spec.containers entries, setting command. Use of Procfile in Hephy Workflow simplifies this problem for operators.

Footnotes:

1 On AWS, CodeBuild can be substituted here to do a similar Dockerfile-driven image build to your own specifications, and Weave Flux/Helm Operator can be substituted for the Deis Controller-based Deployment objects and services, for scaling this deployment to fan out concurrently, or with other CI build systems than the example Hephy Workflow.

Back to top