Continuous Delivery for Windows?

  • Eric M Russell (10/9/2014)


    We've already seen SQL Server move to a pace that releases new versions every two years and bimonthly patches to fix issues. Imagine that we could get patches even more often, as bugs are fixed.

    I'm not the sysadmin side of things, so I'm not sure, but does applying a SQL Server patch typically require a restart of the service? If so, then that would be inconvenient if it occurred every couple of weeks, especially for a standalone non-clustered instance.

    I think most of them do. I don't apply many CUs, just SPs.

  • Andy sql (10/9/2014)


    An already very complex OS would become far more complex to manage, if patches were written for specific configurations. The possible variations would explode, along with the testing required. Nice idea, for sure, and maybe some clever person can figure out how to deploy continuous delivery.

    For the production environment though, I'm far more interested in a stable platform. Unnecessary "feature" updates are undesirable. At best, the platform remains as it was before the update (i.e. working). It can only go downhill from that starting point.

    For me it's less that they'd build separate patches, but if they find that a Windows patch has issues with Surface tablets, they could release a new patch to undo the old one only for Surfaces. Then when they fix things, they can release a new patch to everyone.

  • Steve Jones - SSC Editor (10/10/2014)


    Gary Varga (10/9/2014)


    As someone who accepts all patches as soon as they are available, it sounds good to me.

    As someone who relies on DBAs testing patches before releasing them into live, a am a little nervous about this.

    Yikes! I need your blog or twitter. I rarely accept anything until it's been tested by people like you for at least a few weeks.

    All in the profile 😉

    I rarely have been bitten by patch/update issues in dev. Having said that, I certainly wouldn't treat production machines like I do dev. Also, test must match production, not dev, as much as possible. This includes OS, systems (e.g. RDBMS'), frameworks and applications. A dev machine should not be treated like a model office machine at all!!!

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • djackson 22568 (10/9/2014)


    IMO Microsoft didn't go to a two year release cycle with SQL to improve the product - they did it to improve revenue. Since they only support the last couple releases of an OS, more frequent OS releases would benefit nobody but Microsoft and their shareholders, while costing business huge amounts of money for no return on investment.

    I think this was the plan, but I think they've seen that far less upgrade than they thought. However, they can charge more for new features this way, and possibly they get more revenue over time as a few upgrade every 2, 3, 4 versions and others spend more quicker.

    ...

    Businesses aren't in business to purchase Microsoft products. They are in business to sell cars, electronics, food, et cetera. Spending millions to replace an OS that works perfectly well simply because Microsoft wasn't satisfied with the transition to a newer version, does NOT benefit those businesses.

    Absolutely true. If it works, why change it? Maybe for taxes, but plenty of businesses do or don't buy new vehicles, change offices, etc. often when it's a large expense. IT is getting to be like this. Remember the 3 year hardware refresh cycle? Seems to be slowing down outside of developers.

    ...

    In the meantime, Linux and other open source products are going to continue gaining market share.

    Yes and no. I see lots of companies using Java server side, and looking OSS, but on the desktop, many have given up. However there are more services available.

  • Gary Varga (10/10/2014)


    Steve Jones - SSC Editor (10/10/2014)


    Gary Varga (10/9/2014)


    As someone who accepts all patches as soon as they are available, it sounds good to me.

    As someone who relies on DBAs testing patches before releasing them into live, a am a little nervous about this.

    Yikes! I need your blog or twitter. I rarely accept anything until it's been tested by people like you for at least a few weeks.

    All in the profile 😉

    I rarely have been bitten by patch/update issues in dev. Having said that, I certainly wouldn't treat production machines like I do dev. Also, test must match production, not dev, as much as possible. This includes OS, systems (e.g. RDBMS'), frameworks and applications. A dev machine should not be treated like a model office machine at all!!!

    I am dealing with a group that believes patches should be pushed to the technical teams PCs first. It is only a matter of time before a patch breaks all of our machines, and we aren't able to support the organization.

    No test PCs.

    Seriously.

    Dave

  • Steve Jones - SSC Editor (10/10/2014)


    djackson 22568 (10/9/2014)


    IMO Microsoft didn't go to a two year release cycle with SQL to improve the product - they did it to improve revenue. Since they only support the last couple releases of an OS, more frequent OS releases would benefit nobody but Microsoft and their shareholders, while costing business huge amounts of money for no return on investment.

    I think this was the plan, but I think they've seen that far less upgrade than they thought. However, they can charge more for new features this way, and possibly they get more revenue over time as a few upgrade every 2, 3, 4 versions and others spend more quicker.

    ...

    Businesses aren't in business to purchase Microsoft products. They are in business to sell cars, electronics, food, et cetera. Spending millions to replace an OS that works perfectly well simply because Microsoft wasn't satisfied with the transition to a newer version, does NOT benefit those businesses.

    Absolutely true. If it works, why change it? Maybe for taxes, but plenty of businesses do or don't buy new vehicles, change offices, etc. often when it's a large expense. IT is getting to be like this. Remember the 3 year hardware refresh cycle? Seems to be slowing down outside of developers.

    ...

    In the meantime, Linux and other open source products are going to continue gaining market share.

    Yes and no. I see lots of companies using Java server side, and looking OSS, but on the desktop, many have given up. However there are more services available.

    For hardware refresh, virtualization is changing that. Why do I need to upgrade a server? If it is virtual it can go until the OS is out of support, or the vendor requires an upgrade. VMware hosts can be swapped out far easier, and I think justification is easier as well. Need a new server for that itty bitty department? No. Need a new host, that runs 15 servers? Sure.

    As to OSS, Linux is taking market share. Slowly for sure, but it is happening. Two major cities in Germany have been in the news recently for switching over to Linux.

    If your application is a thick client, it probably requires Windows. If it is a true thin client, and especially if it runs in a browser and is cross browser compatible, it allows the user to move towards OSS. Once enough software allows it, I think the switch is going to accelerate at the speed of light!

    Dave

  • djackson 22568 (10/10/2014)


    Gary Varga (10/10/2014)


    Steve Jones - SSC Editor (10/10/2014)


    Gary Varga (10/9/2014)


    As someone who accepts all patches as soon as they are available, it sounds good to me.

    As someone who relies on DBAs testing patches before releasing them into live, a am a little nervous about this.

    Yikes! I need your blog or twitter. I rarely accept anything until it's been tested by people like you for at least a few weeks.

    All in the profile 😉

    I rarely have been bitten by patch/update issues in dev. Having said that, I certainly wouldn't treat production machines like I do dev. Also, test must match production, not dev, as much as possible. This includes OS, systems (e.g. RDBMS'), frameworks and applications. A dev machine should not be treated like a model office machine at all!!!

    I am dealing with a group that believes patches should be pushed to the technical teams PCs first. It is only a matter of time before a patch breaks all of our machines, and we aren't able to support the organization.

    No test PCs.

    Seriously.

    Ridiculous. I was particularly referring to my personal dev machine (although it might not have been very clear). Enterprise patching, even small companies, should rollout according to a plan which considers business continuity!!!

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • If you want no-fuss upgrades to the latest service pack and bug fixes, then perhaps SQL Azure is the way to go.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • Eric M Russell (10/10/2014)


    If you want no-fuss upgrades to the latest service pack and bug fixes, then perhaps SQL Azure is the way to go.

    Personally, I have switched as much online as possible. It makes changing phone, desktop and servers less problematic knowing that all of my data is online in some form or another. Preferably with local backup, or vice versa. I think it makes sense for companies too, in some circumstances.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

Viewing 9 posts - 16 through 23 (of 23 total)

You must be logged in to reply to this topic. Login to reply