Interesting article was printed in InformationWorld magazine that caught my attention: “Where Agile Fails“. It is an overview of continuous delivery, agile application development and devops movement. As a person who works on a daily basis with development and operations I agree with the author that developers need to be more aware of operation concern. I hear too often developers telling “I am done, it is working on my machine”. Then painful and long process of building, configuration management, deployment and monitoring begins. Blending agile lifecycle with operations, when developers and operation team work together on delivering software product from beginning allow to move project in iterations and with minimal stress to all stakeholders.
Article also emphasize the importance of Deployment pipeline, push button system for easy deploy, configure and test applications into various environments. I think this is a must in modern application development. I hope you enjoy some part I selected from the article Link to the full article“.
Where Agile Fails
“The agile approach to software development has been winning enterprise converts since a group of 17 programmers laid out the core principles in the Agile Manifesto in 2001. The incremental sprints to deliver working software and frequent interactions with business stakeholders that agile requires are widely cheered for keeping soft- ware projects focused on practical goals. But there’s a growing movement to improve agile by making developers accountable for how well their software actually runs in full-blown production mode.
This improvement effort goes by many names: continuous integration, continuous delivery, deployment pipelining, or just plain “dev ops.” It seeks to add the IT operations team as a more important stakeholder in the agile process. Instead of developers being congratulated solely for finishing code that meets the business users’ requirements on time and on budget, they would also be held more responsible for how easily it deploys, how few bugs turn up in production, and how well it runs.
It’s undoubtedly a tall order.
Continuous integration has long been a goal of deep thinkers who contemplate the software development process — partly because it’s so seldom achieved. In a world where developers typically produce code then toss it over the wall to the operations team, devops proposes to bring the two teams together. However, in some ways, agile great success has become a barrier to bringing development and ops together; the agile approach’s need for frequent releases is at odds with operations desire for stable IT systems.
By “operations” we mean the systems and database administrators and other IT infrastructure specialists who keep systems online and serving the business. They often have expertise in how particular applications run and when they’re likely to get overloaded. They know how to configure a new application for deployment, stage it in a pre- production environment, then blend it into all the other operating systems without causing a hiccup in i lie data center. They are also the people who get called on the carpet when hiccups do occur.
Agile advocates consider it essential for agile teams to release code for business stakeholder review early and often. Agile teams also want to update production systems in short ‘and frequent cycles. But operations teams instinctively oppose frequent cycles because that model threatens stability. They’d like update cycles once or twice a year, or at most once per quarter. They have a wealth of all-nighters in he data center and other bitter experience that tells them system failures often follow software updates.
“Developers have no experience in operations —it’s a huge problem,” says developer Jez Humble, co-author with David Farley of Continuous Delivery (Addison-Wesley, 2010). Humble is also a consultant with ThoughtWorks Studios, an agile development consulting firm.
There are other tensions between development and operations. Software often is developed in one environment, then run in another. Developers tend to develop in the environment for which their tools are made, which of- tens means Windows. Testing done in the development environment often misses bugs thai show up in production. Agile tends to focus on testing to confirm that the desired business functionality has been produced but can overlook difficult-to-test attributes, such as scalability, reliability, and ability to sustain peak load performance — attributes prized in operations.
Thus agile development, which has been so successful at connecting the once isolated developer to his business user, has tended to alienate the operations team. Dev ops is trying to extend the gains made with meeting business users’ needs to operations’ needs.
Alternatives From The Web
Computer science courses seldom mention operations, and freshly minted developers naturally gravitate toward “the cool stuff they’re going to build” as opposed to the more staid disciplines of keeping systems running, says Scott Ambler, chief technologist for agile and lean development in IBM’s Rational division and columnist for Dr. Dobb’s (drdobbs.com). “It’s really problem. a blind spot.” Ambler says. Even experienced enterprise IT developers may lack the broad range of experience to prepare them for sharing part of the IT operational responsibility. Yet there might be hope sprouting in the very “cool” companies where young, ambitious programmers want to work: Web companies like Google, Facebook, and Amazon.com that don’t tolerate gaps between development and operations. Amazon CTO Werner Vogels has famously said thai developers should also be operators. Amazon’s e-commerce operation is now organized around discrete application services that are called through an API. Developers of a service at Amazon bear the primary responsibility for its operation throughout its life cycle. “You build it, you own it,” Vogels said in the May 2006 issue of the Association for Computing Machinery’s Queue magazine.
Google and Facebook build new releases and put them in production on a weekly basis, says Ambler. These frequent releases increase risk of failure from an operations point of view, but they also reduce risk by keeping the number of changes included in an update small and manageable. That way, they know where to look if there’s a problem.
Flickr goes a step further and issues multiple releases of production systems daily, says Humble. That led to Flickr experiencing four outages recently, but each lasted only about six minutes, he says— the amount of time that Flickr developers needed to isolate the most recent changes and identify what was wrong. Outages in a new release of a typical enterprise system arc much harder to track down because of the volume of changes.
But large, uniform Web applications such as Facebook or Google are much different from the enterprise data center, with its complex mix of heterogenous applications. When an outage occurs in that environment, it usually results in the dreaded “bridge call,” pulling every expert on the infrastructure together for a lengthy troubleshooting session.
App Dev Needs A Deployment Pipeline
One important step to getting developers and IT operations working more closely is to make sure developers are writing code on the same environment it’ll run on in production. It may sound obvious, but ask around with your developers, and you’ll be surprised at how often that’s not the case.
The next step is to build an automated test capability, so that every build is subject to not only the unit tests and function tests that verify new features but production environment tests that seek to uncover hidden defects.That’s the advice of Jez Humble, co-author of Continuous Delivery and a consultant with ThoughtWorks Studios, an agile development consulting firm. The testing process should serve as an extension of the production environment, Humble says, so thai software that’s passed all the testing can be deployed with the push of a button, instead of a lot of manually written scripts, painful setbacks, and impromptu patches. Humble call i this the “deployment pipeline”—a well-defined environment where coders know if the software works or doesn’t, operations doesn’t have to discover problems on its own.The upside for developers is that, if the pipeline approach works they can submit code for deployment more often,since operations trusts it will not break the system.
“Developers have to own the SLAs,” Humble says. They’re the ones who get called In the middle of the night if the software doesn’t live up to expectations.”