search

ai-cfia / dev-rel-docs

Developer Relations Documentation
MIT License
2 stars 0 forks source link

Fixes #79: Write an ADR about development environments #80

Open vivalareda opened 1 year ago

vivalareda commented 1 year ago

79

also closes #56 I didn't realise I already had a issue open about this my mistake

rngadam commented 1 year ago

From now on, please also put @ThomasCardin as reviewer on any DevSecOps PR

vivalareda commented 1 year ago

From now on, please also put @ThomasCardin as reviewer on any DevSecOps PR

I use to do that but the thing was a lot of PRs were getting approved even when he didn't review them yet since he's working only 2 days I'll add him from now on just wanted to give my opinion

and true on ADR I should always add him my mistake

rngadam commented 1 year ago

I use to do that but the thing was a lot of PRs were getting approved even when he didn't review them yet since he's working only 2 days I'll add him from now on just wanted to give my opinion

the rule, if the person is absent (vacation, not working, etc), you consider their approval optional; at least they'll be able to comment when they are back with the PR. Also a reason why we shoudn't delete branches as soon as a PR is merged.

vivalareda commented 1 year ago

I use to do that but the thing was a lot of PRs were getting approved even when he didn't review them yet since he's working only 2 days I'll add him from now on just wanted to give my opinion

the rule, if the person is absent (vacation, not working, etc), you consider their approval optional; at least they'll be able to comment when they are back with the PR. Also a reason why we shoudn't delete branches as soon as a PR is merged.

I was not aware about that rule will do

rngadam commented 10 months ago

@ThomasCardin this is an important ADR that we need to expand on to explain how we will maintain and deploy our development environments. I've added it back to the DevSecOps backlog.

rngadam commented 9 months ago

@ThomasCardin can you follow up on this one? I do want us to clarify what our different environments (branch, staging, prod) are in order to explain the differences to incoming developers.