Is this release management approach correct?
Hello,
With the team we are working on an application written in Angular (FE) and Csharp(BE). I have a team of about 10 BE&FE developers. We manage our work in AzureDevops using other Microsoft solutions adapting some of scrum and devops project management concepts metodologies. Although we work in sprints, they don't matter much, releases are the most important aspects.
In the team, we mark a certain number of tasks and include them into releases ( like 1.0) then, we work on for some time and relaes it. Here is where my doubts begins - is the approach we are following correct? i've draw some diagram on how the releses are done:
On diagram above we might work on some of features on release branch and merge it into Release --> Stage --> PROD
in the same time, other developers are working on new functionalities and merge them into huge branch /2902 --> DEV -> Stage --> PROD
DEV and QA basically have the same purpos, only Stage to Production pushes are formal.
Are there any weaknesses of this approach? i feel like promotion of environment should look different
Does this approach work for the team? Are there any observed problems? That's where I would start. There are a lot of different approaches for approaching the release process depending on the context. If there aren't any problems or a specific idea to improve the process, it may not be worth changing until there's a concrete idea.
DEV and QA basically have the same purpos, only Stage to Production pushes are formal.
Are there any weaknesses of this approach? i feel like promotion of environment should look different
One weakness is that work seems to pushed rather than pulled. The demand for usable increments of value is unclear.
So where are the pull signals coming from, and is the team able to respond to each of them by planning and releasing at least one Done finished increment in no more than one calendar month?
Although we work in sprints, they don't matter much, releases are the most important aspects.
Why are releases most important aspect? Why are these valued?
we mark a certain number of tasks and include them into releases ( like 1.0) then, we work on for some time and release it.
Tasks, as in sprint backlog items? Any goal for each sprint? Product goal/product roadmap?
What is being measured at your employment to define success for your team and yourself?
Do you delivere a incriment at least once each sprint?