Protect pushes from wrong branch

[nathansamson]

TLDR; I want to protect certain apps to only be pushable by a certain branch, and preferably not allow forced pushes (similar to gitlabs protected branches - https://about.gitlab.com/2014/11/26/keeping-your-code-protected/).

This to prevent accidental pushes to my production application.

Long story.

Lets say I have an app, and I have different environments (test, preprod, production, various short-lived test branches, ...) for this app. Each of these environments is linked to a branch.

• test -> master
• preprod -> stable
• production -> (also) stable
• feature-x -> feature-x
• you get the idea...

To deploy a new version I just do git push deis-production stable and all is well.
Another developer/ops guy takes an old version of stable, does an emergency commit + deploy and does a git push deis-production stable --force as well.. (In theory he should have checked why he needed to force, but sometines in the heat of time you don't think too well)

Alternatively (and this does not require a --force so is more easy to do accidently) one of the deployment guys does git push deis-production master (either he intended to deploy to test, or intended to deploy another branch).

If there were an option to say deis apps:protect branch-name, to only allow pushes to that application with that branch-name, and enforce non --force pushes, this would prevent these errors

[krancour]

The ability to disable force push makes sense.

On the other issue...

Lets say I have an app, and I have different environments (test, preprod, production, various short-lived test branches, ...) for this app. Each of these environments is linked to a branch.

That's pretty common. I just want to make sure I understand you properly, though. Each of the "environments" you allude to is a separate Deis app with its own git remote, yes? So the problem is that when juggling many remotes, you want to avoid the possibility of, for instance, pushing the environment A branch to the environment B remote.

That seems pretty reasonable to me and I'll look into it.

In the meantime, I can offer a suggestion. I have addressed this in the past by putting Jenkins in between the developers / ops guys and Deis. I did this for an organization with specific prohibitions against developers deploying directly from their laptops-- way too many things can go wrong (as your issue illustrates). With Jenkins acting as a middle man, devs have no need to juggle multiple remotes. They can simply push or PR their changes to the appropriate branch, just as they would without Deis in the picture and that can trigger Jenkins to do a deploy. Alternatively, you could have that trigger a test suite, with the deployment set up as a downstream job that is triggered after tests pass.

Some other benefits to having Jenkins in the middle would be robust support for notifying all stakeholders when a deploy is triggered, succeeds, or fails. You can even make production-deployment push-button instead of continuous and use your favorite authorization plugins to enforce who can deploy to production.

Just some thoughts to help you out in the interim. Personally, I'd continue recommending that approach even after this issue has been addressed.

[acr92]

+1 on the Jenkins approach. That's how I would do it.

In addition, (unless this has changed recently?) when the builder is restarted all repositories will be re-created, thus it would be possible for the first person, after a builder reboot, to force push (since we would no longer know the previous history of the repository).

[nathansamson]

@krancour You are exactly understanding what I mean

And yeas I considered the CI/CD approach (I actually use gitlab CI, and wanting to use https://github.com/travis-ci/dpl#deis).

But still I think this might live in Deis as well. Although I understand the problem with the deis-builder being relocated...

[krancour]

But still I think this might live in Deis as well.

Yup. I'm convinced of the need. Now it's a question of whether it's technically feasible and, if so, how to do this most elegantly. Proposals on how would be welcome.

@technosophos wondering if you could weigh in on this as well.

[bacongobbler]

With the re-written builder, do we still accept pushes from all branches or just master on the remote? Ultimately I think this is an unsolvable problem because you can still do git push deis-production stable:master to push the stable branch up to the builder. In other words, there's no good way to protect a branch because users can just push local branches to any remote branch.

[arschles]

Currently the v2 builder accepts pushes on all branches.

[bacongobbler]

I feel like this should be implemented as part of #3722. We should prevent all pushes from occurring while an application is under maintenance mode.

[nathansamson]

I can't see how these are completely related? (except for blocking deploys at given moments, so I guess one change of them should lay the groundwork, and the other change can just reuse some of the logic)

Also I would actually want to deploy while under maintenance mode. One reason for maintenance mode could be that your new version of your application has incompatible database structure so you want to execute the following steps:

1. Put application under maintenance mode
2. Take backup of your database (which is guaranteed to be complete as there won't be new requests)
3. Deploy new version
4. Run migrations
   4a. (Make sure migrations actually ran correctly)
5. Unmaintenance mode

Obviously you can take the following steps as well

1. Deploy new version
   1a. People will see weird errors and crashes just after deploy
2. Put application under maintenance mode (you could actually do this, right after starting the deploy which might prevent the issues in 1a)
3. Take backup
4. Run migrations
   4a. (Make sure migrations actually ran correctly)
5. Unmaintenance mode

This will be the forced method with your proposal. It has the advantage of being less long under maintenance mode, but the disadvantage of having unexplainable problems on your site

[krancour]

Deis v1 is on life support for just a short while longer. Electing to close this as "won't fix."

[nathansamson]

Has this been implemented in deis V2 or is there a related issue for V2?

[mboersma]

@nathansamson no, the behavior in Workflow v2.x is essentially the same, and I don't see a similar feature request there. Would you mind doing a copy-and-paste over at https://github.com/deis/builder/issues where it would be more visible? Or I'd be glad to.