deployment related question - how to deal with failed tickets during the deployment? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 5 years ago.

Improve this quest开发者_如何学Pythonion

(web project) Hello, I am using a user stories/ tickets during development. We are also using a sprints(scrum). So one feature is described in one ticket. So in the end of the sprint we do review. After the review we have some tickets finished and some failed. I am very curious how can I only deploy the finished tickets/features.

I was thinking on creating a branch per ticket using GIT. And then merging only finished tickets/branches to one parent branch.

any more ideas?

---

I think any process you choose to use requires some flexibility.

If you use topic branches for each ticket you could choose not to merge any which are clearly incomplete back into your main branch at the end of that sprint. Unfortunately that discourages frequent merging and you're more likely to have significant merge conflicts as everyone tries to merge changes at the end of a sprint rather than as they finish which would give others a chance to rebase those changes into their history. You also need to then make sure to test the resulting merge of all of those features even if each feature seemed complete independently.

If you merge frequently then you can't easily select only those changes which pass review after the fact. You can however adopt a pattern from continuous deployment and build new features with the ability to enable and disable them in your releases. Code changes might be in the main branch but you don't necessarily have to expose new features until they are considered ready. Obviously this has some overhead and only makes sense for certain types of changes.

Finally you might try to avoid performing all of your review work at the end of a sprint. If you can get at least a pair of developers to go over a feature before merging it into your main branch and have decent tests in place you should be able to keep the quality of your main branch contributions high without adding too much of a bottleneck.

Hopefully you can find something that works for you.

---

I was thinking on creating a branch per ticket using GIT. And then merging only finished tickets/branches to one parent branch. any more ideas?

This approach although clean, would we a pain for maintenance and merging. And what if all tickets work fine on their own branch and don't when merged to the trunk?

My suggestions: 1. If creating separate branch per ticket, have the QA to integration testing. 2. If creating seperate branch per ticket, Make sure the Sprint User Stories are independent enough so that they don;t fail once merged.

1. Can you use svn? With svn every check in would create a tag of the source code. svn revert would revert changes for a particular check in related to a specific ticket. I am not sure if that is possible in GIT.

2. Try and keep a lag between your Sprints and the Releases. For eg. Sprints you are working on now, could be deployed 2 weeks later, so you have enough time to do the merging , reverting or planning around this.