in projects where there's no prototype and there's only a vague idea of what the end result will look like, my team (typically) follows this path:
note: we mainly do web apps with a js client and c# rest server.
initialize git repos (one for web client and one for api server) with ci/cd pipelines where every commit to master will push out a build to a live staging server. devs only commit working code after they verify the new feature works locally on their machines. team leaders review the PRs to make sure everythings in order before merging to master happens. we use vertical slice architecture so merge conflicts happen extremely rarely. because one dev only ever modifies files inside one feature folder. devs are required to pull from master into their local branches as much as possible while working with their local/feature branches.
head dev/ architect manually tests/ tries to break the live staging app and makes sure things are heading in the right direction. if the current state of master is stable he/she pushes a tag in the format of v1.0.0 etc. another cd pipeline picks up this tag and pushes a build to the production server. the mongodb library we use enables us to do automated data migrations so production data gets automatically transformed in to the shape of the latest valid schema.
we don't write any automated tests until v1.0 of our production app. as soon as v1 is released we drop everything and start to write integration tests and try to achieve >90% test coverage. we do this as we feel having to write tests drains brain power that we can use to better architect the features we write. and also the requirements/app architecture changes too often until v1 where things are always in a state of flux and having to manage tests is just a waste. we however don't touch our master again until theres a good enough integration test suit.
once v1 is out and test suit is done, then we setup monitoring and analytics.
this is not a holly grail for us and we evaluate our processes depending on the project/task at hand. but the above has served us well so far. and the only pattern/ practise we ask every team member to follow religiously is KISS. if they submit PRs with too much complexity they'll be asked to redo that feature simplified if feasible.
I would say you work in a quite complete team, with different roles and people involved, and which each person have their own responsibilities during the development and delivery.
In your scenario, I miss which is the time between you initialize the Git Repository and the first v1.0.0 is released, an average number.
On the other hand, to me it's strange the next point:
as soon as v1 is released we drop everything and start to write integration tests and try to achieve >90% test coverage
If I understood it correctly, you first release (the application is live and with users) and then you start writing test. Once you have both, v1 out and tests, you start adding the monitoring and analytics.
Why not do that during the development? Why not setup the monitoring since the beginning and also add some testing (maybe not a 90% coverage)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
in projects where there's no prototype and there's only a vague idea of what the end result will look like, my team (typically) follows this path:
note: we mainly do web apps with a js client and c# rest server.
this is not a holly grail for us and we evaluate our processes depending on the project/task at hand. but the above has served us well so far. and the only pattern/ practise we ask every team member to follow religiously is KISS. if they submit PRs with too much complexity they'll be asked to redo that feature simplified if feasible.
trunkbaseddevelopment.com/
Thanks for sharing! :)
I would say you work in a quite complete team, with different roles and people involved, and which each person have their own responsibilities during the development and delivery.
In your scenario, I miss which is the time between you initialize the Git Repository and the first v1.0.0 is released, an average number.
On the other hand, to me it's strange the next point:
If I understood it correctly, you first release (the application is live and with users) and then you start writing test. Once you have both, v1 out and tests, you start adding the monitoring and analytics.
Why not do that during the development? Why not setup the monitoring since the beginning and also add some testing (maybe not a 90% coverage)