You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since the migration from BOSH to Kubernetes (concourse/prod#36), we went from
continuously deploying ci.concourse-ci.org on every commit that made through
the whole pipeline, to only manually doing so from time to time.
For wings, we used to have a pipeline that would make deploying it one click
away.
Nowadays, however, none of those are true anymore: for both hush-house.concourse-ci.org and ci.concourse-ci.org, everything is manual
when it comes to deploying.
By leveraging a continuous deployment (CD) tool, we could have not only solve
the problem of having to manually deploy our environments, but also learn how
others are tackling this problem in a kubernetes-native way (something we don't
know much about).
So far, argocd displayed some interesting characteristics, being a great
canditate:
possibility of defining custom hooks to both deployments and rollbacks
(remembering that our rollbacks involve manual downgrade migrations to
occur)
but that's not necessarily the tool that we should stick to.
tl;dr
problems
i. despite us continuously delivering concourse, all of our environments are
manually deployed (no continuous deployment).
- reducing our ability to learn from the fixes and features we push daily
ii. we don't know how kubernetes-native CD looks like
- prolems that it solves
- how they solve those problems
bet
leveraging a kubernetes-native CD tool (ii) we can get some of our
environments continuously deployed (i).
by forcing ourselves to use a CD tool, we'll learn what's good, and what's
bad.
acceptance criteria
Define a continuous deployment tool to use to allow us to continuously deploy ci.concourse-ci.org, as well as our other environments, outlying pros and
cons.
The text was updated successfully, but these errors were encountered:
cirocosta
changed the title
Investigate kubernetes-native continuous tool to use to automate our environment deployments
Investigate kubernetes-native continuous deployment tooling to use to automate our environment deployments
Feb 11, 2020
Since the migration from BOSH to Kubernetes (concourse/prod#36), we went from
continuously deploying
ci.concourse-ci.org
on every commit that made throughthe whole pipeline, to only manually doing so from time to time.
For
wings
, we used to have a pipeline that would make deploying it one clickaway.
Nowadays, however, none of those are true anymore: for both
hush-house.concourse-ci.org
andci.concourse-ci.org
, everything is manualwhen it comes to deploying.
By leveraging a continuous deployment (CD) tool, we could have not only solve
the problem of having to manually deploy our environments, but also learn how
others are tackling this problem in a kubernetes-native way (something we don't
know much about).
So far, argocd displayed some interesting characteristics, being a great
canditate:
joining
cncf
: Argo proposal for CNCF Incubation cncf/toc#299 - interestingly, not theCD foundation 👀)
(remembering that our rollbacks involve manual downgrade migrations to
occur)
but that's not necessarily the tool that we should stick to.
tl;dr
problems
i. despite us continuously delivering concourse, all of our environments are
manually deployed (no continuous deployment).
ii. we don't know how kubernetes-native CD looks like
bet
leveraging a kubernetes-native CD tool (ii) we can get some of our
environments continuously deployed (i).
by forcing ourselves to use a CD tool, we'll learn what's good, and what's
bad.
acceptance criteria
ci.concourse-ci.org
, as well as our other environments, outlying pros andcons.
The text was updated successfully, but these errors were encountered: