pipenv: deployment workflow

Question

I am thinking about switching from pip & virtualenv to pipenv. But after studying the documentation I am still at a loss on how the creators of pipenv structured the deploy

Answer 1

I've just switched to pipenv for deployment and my workflow is roughly as follows (managed with ansible). For an imaginary project called "project", assuming that a working Pipfile.lock is checked into source control:

1. Clone the git repository:

   git clone https://github.com/namespace/project.git /opt/project

2. Change into that directory

   cd /opt/project

3. Check out the target reference (branch, tag, ...):

   git checkout $git_ref

4. Create a virtualenv somewhere, with the target Python version (3.6, 2.7, etc):

   virtualenv -p"python$pyver" /usr/local/project/$git_ref

5. Call pipenv in the context of that virtualenv, so it won't install its own:

   VIRTUAL_ENV="/usr/local/project/$git_ref" pipenv --python="/usr/local/project/$git_ref/bin/python" install --deploy

   The --deploy will throw an error, when the Pipfile.lock does not match the Pipfile.

6. Install the project itself using the virtualenv's pip (only necessary if it isn't already in the Pipfile):

   /usr/local/project/$git_ref/bin/pip install /opt/project

7. Set a symlink to the new installation directory:

   ln -s /usr/local/project/$git_ref /usr/local/project/current

My application is then callable e.g. with /usr/local/project/current/bin/project_exec --foo --bar, which is what's configured in supervisor, for instance.

All of this is triggered when a tag is pushed to the remote.

As the virtualenvs of earlier versions remain intact, a rollback is simply done by setting the current-symlink back to an earlier version. I.e. if tag 1.5 is broken, and I want to go back to 1.4, all I have to do is ln -s /usr/local/project/1.4 /usr/local/project/current and restart the application with supervisorctl.