4 ms·

I'd try this continuous deployment thing in the finance or maybe in the automotive industry. Let's see how the clients enjoy it.

iMark 12y ago
The article differentiates between deployment and release.
crdoconnor 12y ago
Clients probably will enjoy it provided you have a comprehensive suite of automated tests that you ran before deploying.
- sz4kerto 12y ago
  - "comprehensive suite": you can't mock everything. If you have an algorithmic trading platform, you connect to many 3rd parties and their systems are very complex, poorly documented and they don't work according to the documentation. - "automated tests": traders don't know what they want. They think they know, but they don't. And they will tell you things they don't want, and when you deliver them they'll be angry. - you don't have direct access to production. If something fails, you won't get all the logs because regulatory reasons. Sometimes you won't even get anything. - etc. I see the value of continuous deployment, just wanted to mention that it's not applicable in many-many fields outside of the CRUD bubble.
  - crdoconnor 12y ago
    This is profoundly ironic. Every excuse that you have made for not automating testing I have heard before ("mocking is hard. let's go shopping"). Most commonly, however, these excuses come from the pits of unprofessional software engineering, though - the "CRUD bubble" as you put it. I find it pretty funny that you think "customers who don't know what they want" is a problem that is unique to trading. Or poorly/wrongly documented APIs.
    - sz4kerto 12y ago
      No, I have never said that I think these problem is unique to trading (that would have been a funny thing to say, indeed). "Every excuse that you have made for not testing I have heard before" -- does this fact render the excuses invalid? Yes, mocking is sometimes too hard and you should not do it because the effort never pays back it's cost. And these situations are very common.
      - crdoconnor 12y ago
        >does this fact render the excuses invalid The "mocking is hard" excuse is invalid, yes. Sometimes it can make sense to create a dirt simple adapter whose code you very rarely have to change, which you subject to heavy manual testing. Then you mock that and leave it alone. You can use this when converting a weird protocol into an easier to handle & easier to mock protocol. However, that just moves the point at which you have to mock back a little, and saves you from writing lots of harness code. It doesn't prevent you from doing continuous integration or continuous deployment. It also doesn't mean you shouldn't mock. It also only makes sense if mocking is harder than actually writing, manually testing and deploying this service. >Yes, mocking is sometimes too hard and you should not do it because the effort never pays back it's cost. Testing is hard. Let's go shopping.
    - collyw 12y ago
      He said automated testing. You can still test (and are able to test a lot more things) when you do it manually. You know, like actually use the application as it is intended.
    - xorcist 12y ago
      I don't read them as excuses for not testing. I read them as reasons why automated testing is not enough. Big difference, and worth taking seriously.
      - crdoconnor 12y ago
        They are not excuses for not testing, no. They are excuses for not automating a highly repetitive process.
  - ribs 12y ago
    3rd party systems - since they're complex and poorly documented and don't work like they say they do, the obvious thing to do is to simulate their vagaries and test against that. Trader don't know what they want - you could substitute any kind of stakeholder for "traders". It is the point of stole, to handle evolving requirements. IT'S THE ENTIRE POINT OF AGILE. No access to production - I'm not sure what argument you're making here. And then your assertion about continuous deployment is unsupported, so I won't bother,
radicalbyte 12y ago
They love it: ING Bank Case Study: Improving time to market from 13 weeks to Less than 1 week with DevOps and Continuous Delivery: https://www.youtube.com/watch?v=9jqY_bvI5vk https://www.youtube.com/watch?v=9jqY_bvI5vk
- sz4kerto 12y ago
  It seems they're mostly talking about their client-facing stuff (mobile banking app, etc.). That I can believe. I very much doubt that there isn't a committee who has to sign off every single release of their core infrastructure.
- pjmlp 12y ago
  Surprisingly people only do talks about success stories, not how everything went wrong, which is what happens in most of what typical corporations understand as "Agile".
carrottop 12y ago
Working in an IB, they have "banking agile" - which is to pretend everything on the project is agile but in reality ends up being iterative waterfall. Agile works best when the clients buy into it - accepting the good with the bad. In Finance, the business would love the good from agile, but will quickly decry the bad.

iMark 12y ago

The article differentiates between deployment and release.

crdoconnor 12y ago

Clients probably will enjoy it provided you have a comprehensive suite of automated tests that you ran before deploying.

sz4kerto 12y ago
- "comprehensive suite": you can't mock everything. If you have an algorithmic trading platform, you connect to many 3rd parties and their systems are very complex, poorly documented and they don't work according to the documentation. - "automated tests": traders don't know what they want. They think they know, but they don't. And they will tell you things they don't want, and when you deliver them they'll be angry. - you don't have direct access to production. If something fails, you won't get all the logs because regulatory reasons. Sometimes you won't even get anything. - etc. I see the value of continuous deployment, just wanted to mention that it's not applicable in many-many fields outside of the CRUD bubble.
- crdoconnor 12y ago
  This is profoundly ironic. Every excuse that you have made for not automating testing I have heard before ("mocking is hard. let's go shopping"). Most commonly, however, these excuses come from the pits of unprofessional software engineering, though - the "CRUD bubble" as you put it. I find it pretty funny that you think "customers who don't know what they want" is a problem that is unique to trading. Or poorly/wrongly documented APIs.
  - sz4kerto 12y ago
    No, I have never said that I think these problem is unique to trading (that would have been a funny thing to say, indeed). "Every excuse that you have made for not testing I have heard before" -- does this fact render the excuses invalid? Yes, mocking is sometimes too hard and you should not do it because the effort never pays back it's cost. And these situations are very common.
    - crdoconnor 12y ago
      >does this fact render the excuses invalid The "mocking is hard" excuse is invalid, yes. Sometimes it can make sense to create a dirt simple adapter whose code you very rarely have to change, which you subject to heavy manual testing. Then you mock that and leave it alone. You can use this when converting a weird protocol into an easier to handle & easier to mock protocol. However, that just moves the point at which you have to mock back a little, and saves you from writing lots of harness code. It doesn't prevent you from doing continuous integration or continuous deployment. It also doesn't mean you shouldn't mock. It also only makes sense if mocking is harder than actually writing, manually testing and deploying this service. >Yes, mocking is sometimes too hard and you should not do it because the effort never pays back it's cost. Testing is hard. Let's go shopping.
  - collyw 12y ago
    He said automated testing. You can still test (and are able to test a lot more things) when you do it manually. You know, like actually use the application as it is intended.
  - xorcist 12y ago
    I don't read them as excuses for not testing. I read them as reasons why automated testing is not enough. Big difference, and worth taking seriously.
    - crdoconnor 12y ago
      They are not excuses for not testing, no. They are excuses for not automating a highly repetitive process.
- ribs 12y ago
  3rd party systems - since they're complex and poorly documented and don't work like they say they do, the obvious thing to do is to simulate their vagaries and test against that. Trader don't know what they want - you could substitute any kind of stakeholder for "traders". It is the point of stole, to handle evolving requirements. IT'S THE ENTIRE POINT OF AGILE. No access to production - I'm not sure what argument you're making here. And then your assertion about continuous deployment is unsupported, so I won't bother,

radicalbyte 12y ago

They love it: ING Bank Case Study: Improving time to market from 13 weeks to Less than 1 week with DevOps and Continuous Delivery: https://www.youtube.com/watch?v=9jqY_bvI5vk https://www.youtube.com/watch?v=9jqY_bvI5vk

sz4kerto 12y ago
It seems they're mostly talking about their client-facing stuff (mobile banking app, etc.). That I can believe. I very much doubt that there isn't a committee who has to sign off every single release of their core infrastructure.
pjmlp 12y ago
Surprisingly people only do talks about success stories, not how everything went wrong, which is what happens in most of what typical corporations understand as "Agile".

carrottop 12y ago

Working in an IB, they have "banking agile" - which is to pretend everything on the project is agile but in reality ends up being iterative waterfall. Agile works best when the clients buy into it - accepting the good with the bad. In Finance, the business would love the good from agile, but will quickly decry the bad.