what is the best way to do / maintain a version of a product ?
-
PIEBALDconsult wrote:
Branching is evil and is a sign of a flawed process.
How do you do an emergency fix of an existing production application?
He doesn't. He changes his name and moves city to avoid them.
-
PIEBALDconsult wrote:
Branching is evil and is a sign of a flawed process.
How do you do an emergency fix of an existing production application?
That depends on the nature of the problem. It's never been an issue.
This space intentionally left blank.
-
That depends on the nature of the problem. It's never been an issue.
This space intentionally left blank.
PIEBALDconsult wrote:
It's never been an issue.
Lets make it more specific. You are working in a company with 20 developers (actual developers not support people) who actively support 8 different products. Each of those products has its own production delivery schedule and each of them goes through following QA process - Development signs off on the current code. - QA (or CM) labels a build, then tests that build - Bugs are cycled back to dev and QA/CM builds/labels/tests until an acceptable level of quality is reached. - QA then specifies a version to deliver and hands that build (the labeled version) to Operations - Operations installs that version. So say Operations is running version 5.3.14. - Development starts or has been working on the next version(s) with some goal that in the future QA will again deliver a version to production. Operations now reports bug that takes down the production server. It is going down once an hour. QA is currently in the processing of validating version 5.7.3. How are you going to fix production?
-
PIEBALDconsult wrote:
It's never been an issue.
Lets make it more specific. You are working in a company with 20 developers (actual developers not support people) who actively support 8 different products. Each of those products has its own production delivery schedule and each of them goes through following QA process - Development signs off on the current code. - QA (or CM) labels a build, then tests that build - Bugs are cycled back to dev and QA/CM builds/labels/tests until an acceptable level of quality is reached. - QA then specifies a version to deliver and hands that build (the labeled version) to Operations - Operations installs that version. So say Operations is running version 5.3.14. - Development starts or has been working on the next version(s) with some goal that in the future QA will again deliver a version to production. Operations now reports bug that takes down the production server. It is going down once an hour. QA is currently in the processing of validating version 5.7.3. How are you going to fix production?
jschell wrote:
20 developers (actual developers not support people) who actively support 8 different products. Each of those products has its own production delivery schedule
That's not too far off from where I worked for much of the 90s, but there were more developers and it was about eight customized versions of one product for at least three operating systems. By the time I started there the product was very stable and I only recall one problem that brought down production at one client site. We were using CMS, with classes, so we knew which version of which file needed to be worked on. It just wasn't an issue. I didn't even know CMS could do branches until I installed it on my own systems a few years ago. I'll also state that if you have a lot of bugs, that's also a problem in your process, and branching isn't going to fix it. If you're already entrenched in the "branches will save us" quagmire, then it's too late.
This space intentionally left blank.
-
jschell wrote:
20 developers (actual developers not support people) who actively support 8 different products. Each of those products has its own production delivery schedule
That's not too far off from where I worked for much of the 90s, but there were more developers and it was about eight customized versions of one product for at least three operating systems. By the time I started there the product was very stable and I only recall one problem that brought down production at one client site. We were using CMS, with classes, so we knew which version of which file needed to be worked on. It just wasn't an issue. I didn't even know CMS could do branches until I installed it on my own systems a few years ago. I'll also state that if you have a lot of bugs, that's also a problem in your process, and branching isn't going to fix it. If you're already entrenched in the "branches will save us" quagmire, then it's too late.
This space intentionally left blank.
PIEBALDconsult wrote:
I'll also state that if you have a lot of bugs, that's also a problem in your process, and branching isn't going to fix it
I will state that in my world problems happen - in production. So solutions are needed - in production. No one cares about broken process when the server is going down every hour. But that doesn't mean that I want to deliver code into production without knowing exactly what is there.
PIEBALDconsult wrote:
If you're already entrenched in the "branches will save us" quagmire, then it's too late.
That of course has nothing to do with what I said.