3 ms·

One thing I would call out: don't do CI to these people. Eat the pain and cut honest-to-goodness versions. Ideally, cut them on the quarter, so that your custom

by pnathan 10y ago

One thing I would call out: don't do CI to these people. Eat the pain and cut honest-to-goodness versions. Ideally, cut them on the quarter, so that your customers can comfortably expect a New Version to be available at a specific time. I used to be on the other side of this desk, so.... trust me. It makes it easier when we can all refer to a specific version. You can throw us specific patches or whatever. From the developer standpoint, you're not delivering a continuously delivered system, you're delivering a "server app" of a specific version.

wmf 10y ago
From experience, on-prem customers won't accept continuous updates anyway. They have multi-month change freezes.
- voltagex_ 10y ago
  Sometimes more - if your product is used in an internal app that has a 6+ month release cycle, they'll be updated in sync (if they're updated at all)
gregmac 10y ago
> don't do CI to these people. Eat the pain and cut honest-to-goodness versions. You say this as if these are opposing things. If you're not doing CI, you're not delivering software properly. On-prem or SaaS is irrelevant. Making release 'versions' is slightly different than continuous deployment (maybe that's what you meant?). There are many ways to do it, I'm a fan of having a 'release/1.2.3' branch (and having the CI system/build scripts automatically pick that version number up and embed it in the source and all output files), but some people use tags to do the same thing. QA team can take the release builds for testing, and dev can merge in bug fixes (either specifically from a gitflow bugfix branch or by integrating in the master branch, depending on your workflow and what other work has happened since the branch was created). Once you have a final GA build, you pin/save it, and give it your customers. Your CI system should absolutely be building the final package you give to your customers (whether it's a zip/tarball, .dpkg/.rpm or setup.exe). If someone has to do something to "get it ready" for customers after the CI build is done, you're not using CI properly.
mr_tristan 10y ago
I think you mean "don't expect to do CD to these people". CI is "developers check in code and everything is integrated daily". CD adds "and then we push it out live if tests pass". I've worked on software products that attempted CD, and it's not gotten a lot of great acceptance. Customers don't really want constant notifications about having to upgrade, except for very serious fixes. And I don't know many IT departments in big companies that are like, "sure, go ahead and auto-update". CI, on the other hand, is wonderful. You don't have the mainline off in this broken state for weeks while you're adding features.
- pnathan 10y ago
  Whoops, yes, you're right. Misnomer. >.>
TorKlingberg 10y ago
Stable versions is the correct way to do it, but it certainly has a cost. You have to support a version with bugs you fixed months ago. You will have to backport security patches and other critical fixes. If you have refactored the code since the stable release merging fixes back to the release branch is much more work. So people will resent the person who made extra work for them by refactoring. Soon everything has the wrong name and functions are 1000 lines long because nobody dares to refactor.
- jasonlotito 10y ago
  > You have to support a version with bugs you fixed months ago. Technically, you do this with any serious SaaS. You cannot just update your service without regarding to existing integrations, and guess what? Those companies are already integrated with you. Having to integrate again is an additional cost, and I promise you, at that moment, they will investigate other options. After all, they are already having to spend additional time/money to update.

by pnathan 10y ago

wmf 10y ago

From experience, on-prem customers won't accept continuous updates anyway. They have multi-month change freezes.

voltagex_ 10y ago
Sometimes more - if your product is used in an internal app that has a 6+ month release cycle, they'll be updated in sync (if they're updated at all)

gregmac 10y ago

> don't do CI to these people. Eat the pain and cut honest-to-goodness versions. You say this as if these are opposing things. If you're not doing CI, you're not delivering software properly. On-prem or SaaS is irrelevant. Making release 'versions' is slightly different than continuous deployment (maybe that's what you meant?). There are many ways to do it, I'm a fan of having a 'release/1.2.3' branch (and having the CI system/build scripts automatically pick that version number up and embed it in the source and all output files), but some people use tags to do the same thing. QA team can take the release builds for testing, and dev can merge in bug fixes (either specifically from a gitflow bugfix branch or by integrating in the master branch, depending on your workflow and what other work has happened since the branch was created). Once you have a final GA build, you pin/save it, and give it your customers. Your CI system should absolutely be building the final package you give to your customers (whether it's a zip/tarball, .dpkg/.rpm or setup.exe). If someone has to do something to "get it ready" for customers after the CI build is done, you're not using CI properly.

mr_tristan 10y ago

I think you mean "don't expect to do CD to these people". CI is "developers check in code and everything is integrated daily". CD adds "and then we push it out live if tests pass". I've worked on software products that attempted CD, and it's not gotten a lot of great acceptance. Customers don't really want constant notifications about having to upgrade, except for very serious fixes. And I don't know many IT departments in big companies that are like, "sure, go ahead and auto-update". CI, on the other hand, is wonderful. You don't have the mainline off in this broken state for weeks while you're adding features.

pnathan 10y ago
Whoops, yes, you're right. Misnomer. >.>

TorKlingberg 10y ago

Stable versions is the correct way to do it, but it certainly has a cost. You have to support a version with bugs you fixed months ago. You will have to backport security patches and other critical fixes. If you have refactored the code since the stable release merging fixes back to the release branch is much more work. So people will resent the person who made extra work for them by refactoring. Soon everything has the wrong name and functions are 1000 lines long because nobody dares to refactor.

jasonlotito 10y ago
> You have to support a version with bugs you fixed months ago. Technically, you do this with any serious SaaS. You cannot just update your service without regarding to existing integrations, and guess what? Those companies are already integrated with you. Having to integrate again is an additional cost, and I promise you, at that moment, they will investigate other options. After all, they are already having to spend additional time/money to update.