search

bblfsh / web

Web client for Babelfish server
http://dashboard.bblf.sh
GNU General Public License v3.0
23 stars 21 forks source link

Add Helm deployment to staging and production #171

Closed meyskens closed 5 years ago

meyskens commented 6 years ago

Depends on https://github.com/src-d/charts/pull/106 and secret setup in travis

meyskens commented 6 years ago

Secrets are set up now

meyskens commented 6 years ago

I would also love to set bblfshd version in yml file too instead of relying on the version in the chart.

Sure that can be done! Will PR it in a moment

meyskens commented 6 years ago

bblfshd and driver versions are now pinned!

Staging will be released on master, production on a version release

smacker commented 6 years ago

Reasoning behind:

Staging will be released on master, production on a version release

All our new projects have CD to staging on push in master. We can verify it works correctly there before tagging new version which makes deployment to production safe.

Though it's different from how blog/landing work and we should review this workflow once again when @dpordomingo is back because he is a maintainer in this project.

rporres commented 6 years ago

The use staging branch to push to staging is quite controversial. I still cannot understand why it is better to use master branch for changes that haven't been tested on staging and may need further changes for issues that were only detected in staging.

If there are projects that use a different schema than the one agreed in https://github.com/src-d/guide/blob/master/engineering/continuous-delivery.md, that has been done without following the written agreements. I'm not saying they're set in stone, I'm just saying they should be followed or changed if they are of no use anymore. That document was written to address issues web team had at the time. Maybe they don't apply now.

I'd love to have time to do deployments per PR, but we're not there yet.

Since I know that at least @mcuadros doesn't like the idea of the staging branch, I'm going to ask him and @smola to weigh in since it may be a good opportunity to change things or leave them as they are.

smacker commented 6 years ago

All projects that we were developing recently:

are deploying to staging on push to master branch, not staging branch. We are pretty happy with that.

I prefer if this project would work like the rest of apps projects. (I don't consider landing&blog apps projects because both of them currently are mostly developing by outsources not by our team)

rporres commented 6 years ago

After bringing the topic to the leads meeting, let's move on with the way you're working in the apps team, @smacker

dpordomingo commented 6 years ago

May be too late... by I think the same than @rporres

https://github.com/bblfsh/web/pull/171#issuecomment-436443948

I still cannot understand why it is better to use master branch for changes that haven't been tested on staging and may need further changes for issues that were only detected in staging.

I do not understand it either. If it didn't happen yet, I'd like to be there https://github.com/src-d/minutes/pull/372#discussion_r232329456

rporres commented 5 years ago

Let's use the workflow proposed by @smacker. See details in https://github.com/src-d/minutes/pull/384

rporres commented 5 years ago

Added a few changes after testing this to be able to properly deploy it. For the moment it cannot be merged as we're working in the fix of an issue related to certificates.