-1

So I have a project which does not have any regression test or automated unit tests. We release every week. We use forking git flow which is basically everyone forks repo and pushes their changes in their specific fork.

From their fork devs push to develop branch which is pushed to pre-prod where tester tests it and then it goes to release. We do weekly releases.

Now sometimes there comes a case when two features are in pre-prod branch one feature is broken and needs to be reverted and other is a priority feature which is needed to be released today. Now what happens is for one feature their are usually 4-5 Merge Requests (including bug fixes) each containing 1-2 commits and sometimes it's hard to revert them.

So in this case what would be the best course of action? Is there a better git workflow more suitable for this scenario? Is there a better way to revert the code than manually reverting each commit? We use Gitlab.

7
  • this post is rather hard to read (wall of text). Would you mind editing it into a better shape?
    – gnat
    Commented Jun 28, 2022 at 8:52
  • 6
    You can't work around a broken process by changing your git workflow.
    – Philip Kendall
    Commented Jun 28, 2022 at 9:02
  • so the only solution to this is to like add automated tests ?
    – user8245171
    Commented Jun 28, 2022 at 10:03
  • You can do it with manual tests, but the cost is more manual repetition of those tests, the key is ensuring that changes are always fully tested before merging, and signed off as 'release ready' before anything is merged. Of course there would still be testing in the release branch too, although you would expect to catch the vast majority of issues before merging (certainly all the major/serious ones that might block a release anyway)
    – Ben Cottrell
    Commented Jun 28, 2022 at 10:16
  • But how will the QA person test before merging it to pre-prod environment
    – user8245171
    Commented Jun 28, 2022 at 11:41

1 Answer 1

Reset to default
4

The problem is that the revert is painful. You somehow discovered a need to revert after the merge was committed to pre-production but before QA tested it. Sounds like someone tested it. That's fine. Do that sooner. Test before the merge is committed next time and it will save a lot of pain.

There is no magic git fix for this precisely because merging code is work. Asking for a revert will always require redoing that work.

This is why we write tests that are meant to be run prior to committing the merge. They aren't the same tests that QA dreams up. They are tests dreamt up by coders who are sick of redoing merges.

If this reads like all I'm saying is that you need automated tests you've missed my point. All code is broken. There will always be bugs.

But what if you can find the bug before QA? Great! Before committing to pre-prod? Even better! Before writing the code? Wow! Before the design? Superb! Before it makes it into the backlog? Awesome!

Why? Because the sooner you find the bug the cheaper it is to fix.

Finding bugs isn't something you leave to QA. There is no point in software development where you shouldn't be looking for bugs, no matter who you are.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.