-2

Note: Controller here refers to one from MVCs

Bear with me, I know these are seemingly unrelated. However, I'm inclined to think both are analogous to each other being that they're means to the same end (i.e. safe product release).

Background: you want to safely push new updates without breaking existing product. Assume it was functioning properly. With feature branches, you can easily rollback to the last stable version. With extended controllers, you can use your DI to inject or swap in the implementation without new, shortlived feature.

How do both methods compare against each other? Which is safer? I feel extended controllers minimise impact for failure given the surface area to test is smaller than replacing the existing controllers and testing them as if they're brand new. In addition, this is in line with the Open-Closed SOLID principle.

On the other hand, I fear continous extension will eventually lead to maintaining an internal git and we may get confused given sufficient parallel features shelved for plug and play.

Does git absolve the need for extending controllers for this purpose or maintaining interchangeable parts?

Improve this question
2
  • These two are not opposites or mutually exclusive. You should be always be using branches and merges to manage your production codeline, period. The choice whether to modify vs. extend any particular component is a separate design decision which is highly situational. If you extend, you still need to modify other code or configuration to consume the extension; both the extended code and the modification need to be checked into source control and tested before promoting to production. Commented Sep 27, 2021 at 17:40
  • @john wu yes, of course. All code should be destined for VCS. I'm asking for the specific case of feature branching i.e. The practise of developing features on a branch and shelving or redeploying that when done. I tried that at my previous workplace but it didn't work out the way we envisioned, so I'm considering extension as an alternative Commented Sep 30, 2021 at 13:04

2 Answers 2

Reset to default
0

The problem with any change to the code is that you can't limit its scope.

Upgrading, or rolling back ControllerA might break ControllerB

To deploy a new version of a codebase

  1. build version 2
  2. deploy version 1 to new boxes
  3. route traffic to version 2
  4. wait for errors
  5. route traffic back to version 1

This way version 1 remains untouched and running the entire time. If you just deploy new versions over the top of old you can't reliably roll back. Even if your code is perfect you still have configuration, OS updates, deployment errors etc

Improve this answer
0

Here's my view: I hate(!!) "injection!"

And here's why: "because now, when I look at 'the source code,' I can no longer tell for certain 'what it actually does, in this particular deployment, in this particular case.'" There is now a tremendous amount of "out-of-band material" which directly interferes with "my ability to debug the dammed thing!"

However – your overall set of questions are, in my view, "too large and maybe too abstract to be dealt with in this forum." I would suggest that you explore other planets within the StackExchange solar system.

Improve this answer
1
  • I've gone through all the other forums. Can't really say I found one matching better than here. Perhaps, you can suggest which ones you have in mind. To your answer, are you sure you understand what I mean by DI? It's specific purpose is for you to always have a central point of detecting what implementation is in active service Commented Oct 3, 2021 at 7:58

Your Answer

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

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.