3 ms·

I don't understand this part: > In the classic software delivery process (development → packaging → distribution → install → deployment), code passes through m

I don't understand this part: > In the classic software delivery process (development → packaging → distribution → install → deployment), code passes through many hands before it finally reaches the end user. Developers build, QA verifies, ops deploys, and finally end users can access. In this environment, the feedback loop for information about how code behaves in production is slow and inefficient — it may take weeks or months for this to make it back to developers, and often in a highly-filtered format. > Heroku is built for the new era of software-as-a-service. An app is built by a small, cross-functional, relatively independent team which builds and deploys everything itself, with few or no hand-offs to other teams. What's the difference here? Developers still build and QA still has to verify. If your code is split up into several repositories, you still want to track versions (packaging & distribution, even if a package is just a branch + revision number).

Volpe 15y ago
They are talking about 'cross functional' teams. So Devs/QAs/Ops can be in the same team, even the same people. Because they (Heroku) are handling all the edge-knowledge of server setup/maintenance etc. You only need to track revision number, in a single repo (maybe with branches, sure). I'm not sure what you mean by "code split into several repositories" ? The difference is deployments become cheap thus "delivering software" becomes cheaper.
- aphexairlines 15y ago
  By several repositories, I mean libraries. Maybe built by your team, maybe by another team. And I still don't see how Heroku hosting your software affects whether you have dedicated QA staff and whether they're in your team or not.
  - bitops 15y ago
    It has to do with how quickly you can iterate on your production software and what the distance is (in terms of time) between a developer committing a change and that change making it out in front of an end-user. In traditional enterprise software (e.g. insurance) the deployment cycles are long because the organization are large, heavily layered, and extremely resistant to change. There are many reasons for this, some sensible and some not. (And then some that are legislated - they fall into both categories). For a startup that is trying to build a service, or a mid-sized corporation, particularly in the ecommerce space, the faster you can change a deployed solution, the better off you are. Say you're running a large ecommerce website and a bug is discovered on the user account page. It's a "P1 issue" that needs immediate attention, i.e. as long as the bug exists, revenue is impacted. In a situation like this, you want to be able to identify a fix, commit it, and ship it to production ASAP. This becomes an issue in traditional organizations where the "developers" are different from "the network people" who themselves are subdivided into database/network/sysadmin/etc. These groups are change-averse and tend to gate releases into maintenance windows. Which makes sense, but can hinder rapid deployment. If you don't have a traditional Ops team, there's no stakeholder who feels you're impinging on their fiefdom when you wantonly hit the deploy button. (Though I don't mean to imply that you shouldn't have discipline around releases). The question you're asking is very relevant for teams making the transition to processes like Agile and infrastructures like Cloud. Because these things are disruptive, they lead to change and break-down of traditional org structures. A dedicated QA department always seems to be one of the first things targeted. (Though I don't necessarily think that's a good idea).
    - aphexairlines 15y ago
      I think you will find that even in large organizations with dedicated teams owning server ops, if a problem is impacting customers in the middle of the day, there will be a way to get the deployment window open quickly. Doing away with maintenance windows altogether sounds great from our point of view as developers, but it shouldn't come at the expense of customers suffering horrible latency during peak hours because the servers are at reduced capacity while a significant percentage of them are busy with deployments. I understand the benefits of rapid iteration through continuous deployment (and intensive automated testing), but cloud platforms like Heroku and Beanstalk don't really help here. Cloud deployment and the ability for developers to push a button and have their changes show up in production quickly also doesn't mean you don't need QA anymore. That's a separate decision. I understand that making deployment a simpler process through hosted server farms is great in that it takes off a lot of pressure from your ops team, but that doesn't change the development process.
dr_rezzy 15y ago
Right, the justification here is a bit blurry. The framework they present is pretty much J2EE redux. If you are going to take this angle, stick with Tomcat and its huge enterprise base. Unfortunately, this is far from reinventing Java for the web.
SachaLabourey 15y ago
I agree, just because you have less friction with IT doesn't mean you suddenly write high quality code with no bugs. Plug: if you are interested in Java deployment and do not anticipate to write bug-free code just yet, you might want to look at CloudBees: this is not just a production PaaS but it also provides a complete Continuous Integration SaaS based on Jenkins and many other services. Glad to see more action around Java in the cloud!

Volpe 15y ago

They are talking about 'cross functional' teams. So Devs/QAs/Ops can be in the same team, even the same people. Because they (Heroku) are handling all the edge-knowledge of server setup/maintenance etc. You only need to track revision number, in a single repo (maybe with branches, sure). I'm not sure what you mean by "code split into several repositories" ? The difference is deployments become cheap thus "delivering software" becomes cheaper.

aphexairlines 15y ago
By several repositories, I mean libraries. Maybe built by your team, maybe by another team. And I still don't see how Heroku hosting your software affects whether you have dedicated QA staff and whether they're in your team or not.
- bitops 15y ago
  It has to do with how quickly you can iterate on your production software and what the distance is (in terms of time) between a developer committing a change and that change making it out in front of an end-user. In traditional enterprise software (e.g. insurance) the deployment cycles are long because the organization are large, heavily layered, and extremely resistant to change. There are many reasons for this, some sensible and some not. (And then some that are legislated - they fall into both categories). For a startup that is trying to build a service, or a mid-sized corporation, particularly in the ecommerce space, the faster you can change a deployed solution, the better off you are. Say you're running a large ecommerce website and a bug is discovered on the user account page. It's a "P1 issue" that needs immediate attention, i.e. as long as the bug exists, revenue is impacted. In a situation like this, you want to be able to identify a fix, commit it, and ship it to production ASAP. This becomes an issue in traditional organizations where the "developers" are different from "the network people" who themselves are subdivided into database/network/sysadmin/etc. These groups are change-averse and tend to gate releases into maintenance windows. Which makes sense, but can hinder rapid deployment. If you don't have a traditional Ops team, there's no stakeholder who feels you're impinging on their fiefdom when you wantonly hit the deploy button. (Though I don't mean to imply that you shouldn't have discipline around releases). The question you're asking is very relevant for teams making the transition to processes like Agile and infrastructures like Cloud. Because these things are disruptive, they lead to change and break-down of traditional org structures. A dedicated QA department always seems to be one of the first things targeted. (Though I don't necessarily think that's a good idea).
  - aphexairlines 15y ago
    I think you will find that even in large organizations with dedicated teams owning server ops, if a problem is impacting customers in the middle of the day, there will be a way to get the deployment window open quickly. Doing away with maintenance windows altogether sounds great from our point of view as developers, but it shouldn't come at the expense of customers suffering horrible latency during peak hours because the servers are at reduced capacity while a significant percentage of them are busy with deployments. I understand the benefits of rapid iteration through continuous deployment (and intensive automated testing), but cloud platforms like Heroku and Beanstalk don't really help here. Cloud deployment and the ability for developers to push a button and have their changes show up in production quickly also doesn't mean you don't need QA anymore. That's a separate decision. I understand that making deployment a simpler process through hosted server farms is great in that it takes off a lot of pressure from your ops team, but that doesn't change the development process.

dr_rezzy 15y ago

Right, the justification here is a bit blurry. The framework they present is pretty much J2EE redux. If you are going to take this angle, stick with Tomcat and its huge enterprise base. Unfortunately, this is far from reinventing Java for the web.

SachaLabourey 15y ago

I agree, just because you have less friction with IT doesn't mean you suddenly write high quality code with no bugs. Plug: if you are interested in Java deployment and do not anticipate to write bug-free code just yet, you might want to look at CloudBees: this is not just a production PaaS but it also provides a complete Continuous Integration SaaS based on Jenkins and many other services. Glad to see more action around Java in the cloud!