urn:lsid:ibm.com:blogs:entries-f0c7afc6-81fd-40d8-a7ae-0775c21390bbEnterprise DevOpsDevOps is a movement, rooted in the agile community, to improve the collaboration between the development and operations teams, speeding software delivery and improving quality. While the DevOps has traditionally focused on "born on web" companies, IBM'030112014-12-04T04:27:33-05:00IBM Connections - Blogsurn:lsid:ibm.com:blogs:entry-4f61dee3-34ef-49a7-a158-8b706a828a92Adapting to the Pace of Business with DevOpsmdelder120000CYNEactivefalsemdelder120000CYNEactivefalseComment EntriesLikestrue2013-05-03T15:49:29-04:002013-05-03T15:49:29-04:00<p dir="ltr">
<!--?xml version="1.0" encoding="UTF-8" standalone="no"?--></p>
<div dir="ltr">
<!--?xml version="1.0" encoding="UTF-8" standalone="no"?-->
<div>
<!--?xml version="1.0" encoding="UTF-8" standalone="no"?-->
<div>
<span style="font-size:14px;"><span style="font-family:lucida sans unicode,lucida grande,sans-serif;"><span style="color: rgb(0, 0, 0); "><a href="https://www.ibm.com/developerworks/community/blogs/devops/resource/BLOGS_UPLOADED_IMAGES/no_secret_science.jpg" target="_blank"><img alt="image" src="https://www.ibm.com/developerworks/community/blogs/devops/resource/BLOGS_UPLOADED_IMAGES/no_secret_science.jpg" style=" display:block; margin: 1em 1em 0pt 0pt; float: left;" /></a>Last week, Opscode hosted ChefConf, a 4 day event focused on adopters and contributors of Chef. IBM was a Gold sponsor of the event, and several of my colleagues and I had the wonderful opportunity to attend. While there, IBM presented a keynote talk on how we&#39;re adopting Chef as part of our IBM SmartCloud strategy, as well as a more detailed breakout session and kiosk in the exhibition hall.&nbsp;</span></span></span></div>
<div>
&nbsp;</div>
<div>
<span style="font-size:14px;"><span style="font-family:lucida sans unicode,lucida grande,sans-serif;">ChefConf demonstrated the electricity of how DevOps and Continuous Delivery are shaping the future of how businesses compete in the market place. While many great keynotes were given at ChefConf (including Disney, Nordstrom, Facebook, and Jamie Winsor&#39;s (@resetexistence) great talk on Berkshelf), I thought that Adam Jacob&#39;s (@adamhjk)&nbsp;<a href="http://t.co/gST93C4UfY">keynote</a>&nbsp;really summarized why this trend -- although enabled by technology -- is really driven by the needs of the business.&nbsp;</span></span></div>
<div>
&nbsp;</div>
<div>
<span style="font-size:14px;"><span style="font-family:lucida sans unicode,lucida grande,sans-serif;">Adam opened his talk with a discussion of the impact of globalization. In the first phase of globalization, standardization of how we move goods through container-based shipping took about 40 years to take over a majority of goods (minus oil and grain) between countries. The internet achieved similar penetration in about half that time (22 years). As the goods and services become even more dependent on the internet and mobile platforms, new business models emerged and existing business models were forced to adapt. For instance, Adam cited the impact of customer service to the early success of Walmart and how Amazon focused on the same aspect of customer service and volume pricing, but with the application of technology to improve the consumer experience. He also cited an example of a traditional business adapting through his recent experience with Allstate. When he needed to file an insurance claim -- his claim was serviced through his smart phone.&nbsp;He even described an innovative business model to improve how bananas can be brought to market using mobile phones!&nbsp;(Ubernana, which may officially be Trademarked by Adam :).&nbsp;</span></span></div>
<div>
&nbsp;</div>
<div>
<span style="font-size:14px;"><span style="font-family:lucida sans unicode,lucida grande,sans-serif;">In each example, he demonstrated that &quot;software is the interface for consumption.&quot; In other words, software is the critical fabric that enables businesses to engage and convert users into customers.</span></span></div>
<div>
&nbsp;</div>
<div>
<span style="font-size:14px;"><span style="font-family:lucida sans unicode,lucida grande,sans-serif;">In order to adapt to these business requirements, he stressed the need to break with traditional heavy-oversight driven process and focus instead on empowering the doers and focusing on accountability. We have to change our organizations from a focus just on high level design and more focus on the &quot;full stack engineer&quot; that understands the holistic view of the delivery process and who is empowered to make changes and optimize the delivery process over time.&nbsp;</span></span></div>
<div>
&nbsp;</div>
<div>
<span style="font-size:14px;"><span style="font-family:lucida sans unicode,lucida grande,sans-serif;">Ultimately, Adam&nbsp;believes that the economic impact of what we&#39;re doing with DevOps will move much faster than the first phases of globalization. Even more intriguing, he asserted that when we&#39;re done with the transformation, we won&#39;t look the same at all. Business will change in the structures and roles of the organization to adapt to how quickly we must deliver capabilities in order to meet the needs of our users.</span></span></div>
<div>
&nbsp;</div>
<div>
<span style="font-size:14px;"><span style="font-family:lucida sans unicode,lucida grande,sans-serif;">Perhaps most succinct, he said that &quot;DevOps isn&#39;t about us, it&#39;s about a set of ubiquitous global trends that require new behavior to survive the next few decades in the global economy.&quot;</span></span></div>
<div>
&nbsp;</div>
<div>
<span style="font-size:14px;"><span style="font-family:lucida sans unicode,lucida grande,sans-serif;">Regardless of whether you agree or disagree with Adam&#39;s position, we can all agree that it&#39;s going to be an exciting transformation and journey together!</span></span></div>
<div>
&nbsp;</div>
</div>
</div>
<p dir="ltr">
&nbsp;</p>
<p dir="ltr">
*Image was part of Adam&#39;s talk and was reused from&nbsp;<a href="http://www.flickr.com/photos/dkeats/4128747046/sizes/s/in/photostream/">http://www.flickr.com/photos/dkeats/4128747046/sizes/s/in/photostream/</a></p>
Last week, Opscode hosted ChefConf, a 4 day event focused on adopters and contributors of Chef. IBM was a Gold sponsor of the event, and several of my colleagues and I had the wonderful opportunity to attend. While there, IBM presented a keynote talk on how...003617urn:lsid:ibm.com:blogs:entries-f0c7afc6-81fd-40d8-a7ae-0775c21390bbEnterprise DevOps2014-12-04T04:27:33-05:00urn:lsid:ibm.com:blogs:entry-4abfa8e3-7776-44f1-9838-fa7678498875Wait Makes WasteCindyVanEpps120000EA06activefalseComment EntriesLikestrue2013-01-24T13:43:59-05:002013-01-24T13:43:59-05:00
<span style="font-size: 12pt; font-family: Arial;"><span style="font-style: italic;">“You’ll eat it and you’ll like it!” </span>my Grandma Stowell used to say. Its not that she was a food tyrant but rather that she had spent all day in the kitchen preparing a meal.<br /><br />Now I can go to a restaurant, place an order and be served within 20 minutes or so. The testing and feedback on the product I receive happens immediately. If I determine that it is so delicious I must have more, or that I have capacity for dessert (as if dessert has any pre-conditions!), I can receive more product in the same dining event.<br /><br />Through streamlined processes and technology, I can drive up to a window, place a food order, and receive it within minutes. Usually I get exactly what I want and am happily on my way. But on the rare occasion something goes awry – for instance, if I protest the size or warmth of my chicken nuggets; I can get my order replaced in under 30 seconds while I wait.<br /><br />Whether I am at a fast food restaurant or a diner, I don’t really care if the preparers are the same as the servers. I really care that I get my requirements met quickly and that the product is acceptable quality. If I need to adjust the order based on missed expectations, I expect to do that also in an acceptable time frame.<br /><br /><span style="font-weight: bold;">DevOps is the PrepServe of software delivery. </span> </span><a '="" href="https://www.ibm.com/developerworks/mydeveloperworks/blogs/devops/resource/BLOGS_UPLOADED_IMAGES/Serve.jpg
" target="_blank"><img alt="image" src="https://dw1.s81c.com/developerworks/mydeveloperworks/blogs/devops/resource/BLOGS_UPLOADED_IMAGES/Serve.jpg" style=" display:block; margin: 1em 0pt 0pt 1em; float: right; position:relative;" /></a> <br /><span style="font-size:12.0pt;font-family:Arial;mso-fareast-font-family:Batang;
mso-ansi-language:EN-US;mso-fareast-language:KO;mso-bidi-language:AR-SA"><br />The old adage “haste makes waste” is based on the principle that making a mistake requires a costly return to the beginning of the work because of loss of large blocks of time required to accomplish the work and the loss of resources wasted in starting over. <br /><br />Consider how technology has advanced the software delivery world. We have the ability to collaborate to specify and understand requirements, even with time zone challenges, in days rather than months. Delivering in smaller increments of capabilities not only gets capability in the hands of the users faster (the pot o’ gold of agile methods) and it also greatly reduces the time it takes to isolate the cause of a defect. Automated testing ensures that tests can be run more often and test results are collated and reported in hours and minutes rather than days and weeks. Virtualized services reduce the cost of complex test environments from millions of dollars down to hundreds. Capturing infrastructure as code ensures that development and test environments are “production-like” to reduce the risk of error resulting from environment inconsistencies.<br /><br /><span style="font-weight: bold; font-style: italic;">With software delivery, wait makes waste.</span> In the time it takes to develop a large system, <span style="font-style: italic;">the players change</span>. The business analyst who is assigned to user acceptance test your product 1 year after someone else specified the business requirements likely will not understand the original intent. <span style="font-style: italic;">Technology changes</span>: the architectural constraints as well as the business analysts’ technology frame of reference that impacted the original requirements are likely far different. <span style="font-style: italic;">Business drivers change</span>: competitors advance their products and approaches. <span style="font-style: italic;">Resources change</span>: this year’s budget cycle may not provide the developers, enablement program, or infrastructure that your large system change requires.<br /><br />A most poignant example of wait makes waste happened when I worked in software development for Space Shuttle Mission Control at Johnson Space Center, NASA. We were collecting the requirements to procure the first set of distributed systems' hardware to start migrating Space Shuttle Flight Design off the mainframe. In order to ensure a low cost solution, the NASA executive sponsor explicitly captured the requirement that the monitors in the new system would be black and white displays. At the time, color monitors were bleeding edge technology. During the many months of the request, bid, and award to vendor process, the chosen vendor had advanced their technology so that color monitors were their primary product. <span style="font-style: italic;">We actually paid the vendor to downgrade the capability in their primary product to meet the specific requirement!</span> Needless to say, I was disappointed both as a system user and as a tax payer.<br /><br /><span style="font-weight: bold;">“You’ll eat it and you’ll like it!”</span><br /><br />It is an extreme example, but certainly represents the paradigm for delivery of business value in software that many business users have come to expect as their reality: belabored and detailed processes that in the name of “haste makes waste” cannot be streamlined. I provide the food acquisition examples to encourage that there is a better way. DevOps provides fast service and an immediate feedback loop but those are really the means to the end – customer satisfaction. And for business users dependent on software systems, their satisfaction is delivered as functionally appropriate, secure, available, responsive and easy-to-use systems. <span style="font-style: italic;">Can you biggie size that for me, please?</span><br /><br /></span>
“You’ll eat it and you’ll like it!” my Grandma Stowell used to say. Its not that she was a food tyrant but rather that she had spent all day in the kitchen preparing a meal. Now I can go to a restaurant, place an order and be served within 20 minutes or so. ...103394urn:lsid:ibm.com:blogs:entries-f0c7afc6-81fd-40d8-a7ae-0775c21390bbEnterprise DevOps2014-12-04T04:27:33-05:00urn:lsid:ibm.com:blogs:entry-39413631-8a62-43a9-b45a-99ae10b6384fMaking Your Automated Tests Fasterann_marie_9906000073UAactivefalseComment EntriesLikestrue2012-11-06T17:14:18-05:002012-11-14T09:11:26-05:00
<span lang="en" sizcache="25" sizset="122"><p>One part of my job is helping other teams adopt DevOps in general, and continuous delivery in particular. But I have a problem: many of them have a suite of automated tests that run slowly; so slowly that they only run a build, and the tests that run in the build, about once per day. (Automated test run times of 8-24 hours are not uncommon.) There are several reasons why this is the case, including:</p><ul><li>The artifacts that are produced from the build, and then copied over to the test servers, are very large (greater than 1 GB in size). Also, sometimes the artifacts are copied across continents.</li><li>Sometimes there are multiple versions of the build artifacts that must be copied to different test servers after the build. A typical product I deal with will support at least a dozen platforms; a few support around 100 different platforms, when you multiply the number of supported operating system versions times the number of different components (client, server, gateway, etc.) times 2 (for 32- and 64-bit hardware).</li><li>Often, the database(s) for the product must be loaded with a large amount of test data, which can take a long time to copy and load.</li><li>Many products have separate test teams writing test automation. Testers who are not developers tend to write tests that run through the UI, and those tests are usually slower than developers' code-level unit tests.</li></ul><p>Running builds and tests often, so developers know when they make a change that breaks something else, is a key goal of both continuous integration and continuous delivery. Ideally, a developer should get feedback on whether their code is &quot;ok&quot;, using a quick personal build and test run, within 5 minutes. Anything over 10 minutes is definitely too slow; the developer will probably move on to something else, make more changes, and forget exactly what was changed for that particular test.</p><p>Once the quick tests pass, the developer can run a full set of tests and then integrate the tested changes. Or, in cases where a full set of tests is extremely slow, the developer can integrate his or her code changes once the quick tests pass, and then let the daily build run the full set of tests.</p><p sizcache="25" sizset="122">I proposed a DevOps Days open space session on this topic at <a href="http://devopsdays.org/events/2012-italy/">DevOps Days Rome 2012</a>. We brainstormed ways to make automated tests run more quickly. We focused more on quick builds for personal tests, but most of these ideas would make the full set of tests faster too. Many thanks to the dozens of smart people who contributed their ideas. I don't even have their names, but they know who they are. I'm sure we'll use several of these ideas right away.</p><div> </div><h1>Fail quickly</h1><div>Often, tests are run in a silly order - alphabetically, for example, or in the order that they were created. We can be much smarter about the order in which we run our tests.</div><div> </div><h2>Run a quick smoke test first</h2><p>Run a quick smoke test to make sure that the infrastructure and services your tests will need are available. Can you ping the servers you need, connect to your databases, etc.? Ideally, this should only take a few seconds to a minute. If some critical part of the infrastructure is missing, there's no reason to waste time setting up the rest of the tests.</p><p>By the way, running smoke tests often on your production servers is a good idea too.</p><div> </div><h2>Run a small set of tests that fail often next</h2><p>With experience, it's easy enough to identify a small set of tests that seem to fail more often than the others. Run those next. Ideally, this should only take a few minutes. If this takes more than 5 minutes, reduce the number of tests in this bucket.</p><div> <h2>Run tests that never fail later</h2><p>If you have tests that are on code that has not changed in a long time, and the tests never fail, you can run them near the end of the series of tests.</p><div> </div></div><h2>Run slow tests last, or not at all</h2><p>Run the slowest test buckets last, as long as earlier tests don't depend on them.</p><p>By the way, as a side note - ideally you would run your tests in a different order now and then. Sometimes a test won't fail unless it's done in the wrong (or is that the right) order.</p><div> </div><h1>Run in parallel</h1><div> </div><h2>Run test buckets in parallel</h2><p>Sad but true - often, tests are run sequentially. Look for ways to run many tests in parallel, even if it means deploying many VMs to do the testing. When you can deploy many VMs cheaply and automatically, then you should take advantage of that to make the testing faster.</p><div> </div><h2>Use snapshots of databases or VMs to make it easier to run tests in parallel</h2><p>You can configure VMs more quickly if the saved snapshot/image that you start with is close to the final system that you need. There's an art to putting enough of your configuration into the VM images to make your deployment fast, without getting into a state where you have far too many VM images to manage.</p><p>You can also create database backups with a lot of your test data pre-loaded, rather than relying on SQL statements or running code to populate the database. In some cases you may be able to leave a database (or several databases) up and running, and reuse the same data over and over again. In other cases you may be able to have a pool of databases that are ready for testing, assign one database from the pool to a test suite, and then revert the database to its original state after the test suite has executed.</p><div> </div><h1>Break up tests into smaller groups</h1><div> </div><h2>Divide your application into components, and test the changed components</h2><p>Most software can be divided into logically separated components, with clearly defined interfaces with and dependencies on other components. Once you do that, you can build and test the components separately before testing them together. If you only have to re-test your own component in personal builds, you won't have to wait as long for results.</p><div> </div><h2>Automatically determine which tests to run when code changes</h2><p>There are some very snazzy systems out there which can automatically decide what tests to run, based on the code that was changed. This is a topic that's too broad for this blog post.</p><div> </div><h1>Save time on I/O</h1><div> </div><h2>Mock responses</h2><p>Instead of contacting actual external services, in personal builds you can mock the services you're not trying to test. For example, you can record the expected response to each request, and play that back. This saves you the time spent in the request/response round trip, and if you are doing many round trips in your tests, that time can add up. There are many open source and commercial tools available to help with this. Green Hat is a great service simulation tool what was recently acquired by IBM.</p><div> </div><h2>Use LXC (Linux Containers)</h2><p>Sometimes you don't need to set up a new virtual machine for testing. LXC may be enough, and it's faster.</p><div> </div><h2>Move servers and data so they are close to one another</h2><p>If you have to copy data across networks, or even across continents, take a long hard look and see if there's a way to avoid it. Even if this means spending money on hardware, software, and setup, it might be worth it.</p><div> </div><h2>Make your test infrastructure faster</h2><p>This seems obvious, but sometimes we forget this option. Use faster hardware, or faster VMs. Do performance tuning on your test infrastructure, including the systems, storage, networks, and so on. For example, some companies use BitTorrent to transfer large files much more quickly.</p><div> <h2>Cache what you can</h2><p>This is going to depend on your specific application, but you should cache what you can, without making your tests less useful or less accurate.</p></div><div> </div><h2>See also: Use snapshots of databases or VMs to make it easier to run tests in parallel</h2><p>Look in the &quot;Run in Parallel&quot; section above. This also saves time on I/O.</p><div> </div><h1>Remove some tests</h1><div> </div><h2>Remove slow tests</h2><p>Set a maximum run time for each test, and enforce it. If an individual test takes a long time to run, it will slow down everything and everyone else. If a test is too slow, you can improve the test itself to make it faster. Or, it may be that the performance of that part of your application is too slow, in which case you should fix the performance of the application.</p><p>People have different ideas on how to enforce this. Some companies created a report of the slowest tests each day or week, and told people to fix them. Others put a timer on each test and automatically made the test fail after a certain amount of time. The idea is that the people writing the tests should feel the pain when their tests are too slow.</p><div> </div><h2>Replace some UI tests with code-level tests</h2><p>If a UI test is slow, and you can test the same thing by testing the API without the UI, then it's usually faster to replace the UI test with an API test.</p><div> </div><h2>Replace some tests with monitoring</h2><p>In some cases, it may be OK to release code that is not fully tested and rely on monitoring to catch any problems. In reality, no code is 100% tested. It's just a question of how much testing you need for your specific business environment.</p><p>A few people also suggested that your running components can report their health back to a monitoring server on a regular basis.</p><p>Note that it's easier for monitoring to help you find where and when problems were introduced if you have &quot;deployment lines&quot; in your metrics -- markers showing when changes were made, with a link to what those changes were.</p><div><div><div> </div><h1>Conclusion</h1><div>I hope you've gleaned a few useful ideas from this article. If you have more to add, please contribute them to the comments section below. Thank you! </div></div></div></span>
One part of my job is helping other teams adopt DevOps in general, and continuous delivery in particular. But I have a problem: many of them have a suite of automated tests that run slowly; so slowly that they only run a build, and the tests that run in the...407328urn:lsid:ibm.com:blogs:entries-f0c7afc6-81fd-40d8-a7ae-0775c21390bbEnterprise DevOps2014-12-04T04:27:33-05:00urn:lsid:ibm.com:blogs:entry-416597f0-2618-4a1f-90c1-8218e6dc06d5Who moved my cheese? - An exploration of the effect DevOps has on roles in the enterpriseDanBerg0600006G7XactivefalseComment EntriesLikestrue2012-09-07T09:26:12-04:002012-09-07T16:01:57-04:00
<div>
<p>
Everyone is painfully aware that as technologies improve and evolve it becomes harder to deliver new features with quality to demanding customers. With new social and mobile applications customers have become trained to having their requests fulfilled within days and weeks versus the more traditional months and even years that we have seen in the past. So as many folks have done you have turned towards <b>DevOps</b> as the savior to help you deliver features faster. However to <b><i>really</i></b> adopt DevOps, one needs to introduce tools that promote good behaviors but you also need to make necessary cultural changes.
</p>
<p>
With the introduction of DevOps into an organization it is not unlike Sniff, Scurry, Hem and Haw having their cheese (success and happiness) moved within the maze of life in the great book <b>Who Moved My Cheese?</b> by Dr. Spencer Johnson. Before the introduction of DevOps within an IT organization, teams were content with slow processes which ensured quality but reduced the organization's ability to be lean and agile. The operations team has full control over all IT processes and changes to environments. They rely on older automation technologies (or manual processes) with little to no management of the changes. Folks were content during these times. It may be slow but no one cared that much as long as the work was done. This is the time in the book when Hem and Haw became content and arrogant because they had a seemingly endless supply of cheese. <br /></p><a '="" href="https://www.ibm.com/developerworks/mydeveloperworks/blogs/devops/resource/BLOGS_UPLOADED_IMAGES/who-moved-my-cheese.jpg" target="_blank"><img alt="image" src="https://dw1.s81c.com/developerworks/mydeveloperworks/blogs/devops/resource/BLOGS_UPLOADED_IMAGES/who-moved-my-cheese.jpg" style=" display:block; margin: 1em 0pt 0pt 1em; float: right; position:relative;" /></a><p><br />
Then the world began to change...</p><p>
The cheese was moved...DevOps principles and tools were adopted.<br /> <br /></p><p>
Now Hem is annoyed, <b>&quot;Who moved my cheese?</b>&quot; The introduction of DevOps principles and tools has changed the game for how changes to environments are defined, managed, and delivered. Thus roles within the organization will need to change and/or emerge to deal with DevOps.</p>
<p>
We are going to focus on four roles and the changes we are seeing due to DevOps.
</p><ul>
<li><b>Release Engineer</b></li>
<li><b>Application Developer</b></li>
<li><b>Infrastructure Specialist</b></li>
<li><b><i>(new)</i> Infrastructure Developer</b></li></ul>
<br />Before we jump into each role I wanted to call out two quotes that I believe are appropriate here. First, a quote from Haw that he chiseled on a wall within the maze:</div><div><br /></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><i><b>If You Do Not Change, You Can Become Extinct</b></i></div><div><br /></div></blockquote><div>The second quote that I really like is the definition of <i>Insanity</i> by Albert Einstein.</div><div><br /></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><i><b>Insanity is doing the same thing over and over again and expecting different results.</b></i></div></blockquote><div><h2><br />Release Engineer</h2>
Generally a <b>Release Engineer</b> is concerned with the compilation, assembly, and delivery of software components. Often the role is responsible with defining and managing the <a href="https://jazz.net/products/clm/features/clm_planning/">Release Plan</a>, which includes the streams and iterations for the release. When folks talk about a Release Engineer they almost immediately think of the person that is responsible for setting up the build process to build the software components.
<p>
</p><p>
With DevOps we are seeing that the role of the Release Engineer is expanding to include the delivery process as well as the build. With new tools such as <a href="https://jazz.net/products/smartcloud-continuous-delivery/">IBM SmartCloud Continuous Delivery</a>, a Release Engineer is responsible for owning and automating the release process to build, package, deploy, and test software changes. The Release Engineer does not work in a vacuum. She must work with architects across the organization (e.g., Application, Operations, Test, etc.) to define which components are involved in a release, what test environments will be required for testing, what standard cloud patterns need to be used for testing, etc. The Release Engineer is the goto person for release process and is responsible for encoding (automating) the release process using DevOps inspired lifecycle process tools.</p>
<h2><br />Application Developer</h2>
<p>
Everyone knows that the Application Developer is responsible for software development that involves the development of application code that will be built into software components. Application Developers are generally multi-lingual which is to say they are skilled in the development of multiple languages (e.g., Java, .Net, Ruby, etc.) and most developers today have some understanding of Agile development principles. These principles include iterative planning and development, test-driven development, module software components, self-documenting code, etc. A problem with many Application Developers is that they have little to no understanding of the operational environment that their code will be deployed which dramatically increases the potential for problems due to invalid assumptions and/or down right ignorance.
</p>
<p>
With DevOps the changes to the Application Developer role vary across organizations. Based on my observations the Application Developer continues to be primarily responsible for the coding and delivery of software components, but the developer cannot work in a vacuum. First the architecture of the application must be defined, readily accessible, and easily understood by everyone on the team (developers, testers, release engineer, operator, etc.). You don't need to have formal <a href="http://www.uml.org/">UML</a> training to document your application architecture (but it doesn't hurt). Even creating a sketch of the architecture that is accessible to everyone would be a great first step. The importance of documenting the architecture is to understand the key components to be deployed and to document the assumptions the components make on the environment. This will help to drive development in the correct direction and avoid costly architectural mistakes that are not caught until late in the release. As you look towards tools, keep your eyes open for tools that allow you to document the architecture directly within code that is ultimately executed by programs to setup and configure environments (note we are exploring options in our <a href="https://jazz.net/products/smartcloud-continuous-delivery/">SCCD project</a>).
</p>
<p>
A second change in the Application Developer role is expanding his knowledge of the operational environment. Granted you will always have specialized developers that live in a vacuum but these will be few and far between moving forward. With DevOps it becomes much more important that Application Developers become operationally aware as they take on more responsibility for the quality of the deployed application and not simply the code. We are seeing that new technologies that are much more intermingled is a driving force for the Application Developer to be more aware of the operational environment. For example a COBOL developer will probably not care about the operational environment as much as a developer who uses Ruby, CSS, HTML5, JSP, Java, .NET, etc. It's this up-skilling on the front end that forces greater awareness of how things fit together. Application Developers generally do not want to be ignorant (I'm an application developer so I can say this). We want to learn and be more productive. What I have seen that works well is to team up application developer with a person from the Operations team that is responsible for reviewing software designs and operational skill transfer.</p>
<h2><br />Infrastructure Specialist</h2>
<p>
The Infrastructure Specialist is traditionally responsible for provisioning and configuring the infrastructure used for test and production environments. Provisioning of environments involves the setup of machines and networks and generally a standard operating system configuration. The Infrastructure Specialist's key responsibility is to ensure that an environment remains functioning at an acceptable level of quality usually captured as service level agreements (SLAs) in some form or fashion. Speed is generally not as important as stability and quality.
</p>
<p>
With the emergence of DevOps the Infrastructure Specialist role changes to be more useful to the business by providing services to request infrastructure on demand. <a href="http://en.wikipedia.org/wiki/Cloud_computing">Cloud</a> is often introduced into the equation to provide self-service and dynamic, programmable infrastructure (Infrastructure as a Service). That is to say that Cloud (or another virtualized platform) provides APIs to quickly and easily provision new virtual machines. The Infrastructure Specialist is also responsible for implementing standards within the virtualized platform such as standard Operating Systems, networking, and storage that encapsulate organizational requirements. The Infrastructure Specialist further increases their value to the business by moving beyond just providing Operating Systems to creating standard platform images (e.g., Application Server, Database, etc.) and even in some cases standard virtual patterns (see <a href="http://www-142.ibm.com/software/products/us/en/smartcloud-provisioning/">IBM SmartCloud Provisioning</a>) which is often referred to as Platform as a Service (PaaS). The standard images and patterns are not created in a vacuum. Just as an Application Developer collaborates on the definition of the application architecture, the Infrastructure Specialist collaborates on the creation of standard virtual patterns to be used by the development teams.</p>
<h2><br />Infrastructure Developer</h2><a '="" href="https://www.ibm.com/developerworks/mydeveloperworks/blogs/devops/resource/BLOGS_UPLOADED_IMAGES/cheese_quote.jpg" target="_blank"><img alt="image" src="https://dw1.s81c.com/developerworks/mydeveloperworks/blogs/devops/resource/BLOGS_UPLOADED_IMAGES/cheese_quote.jpg" style=" display:block; margin: 1em 0pt 0pt 1em; float: right; position:relative;" /></a>
<p>
And now we come to a new role called the <b>Infrastructure Developer</b> but before we can describe this new role we have to discuss <b>Infrastructure as Code</b>. The idea of Infrastructure as Code has been around for a few years within the DevOps community. Carlos Sanchez has a blog simply titled <a href="http://blog.carlossanchez.eu/2012/03/13/infrastructure-as-code/">Infrastructure as Code</a> that does a nice job of stating the key points of Infrastructure as Code. For me the main point is that automation configuration of environments is evolving from basic scripts to new development languages (e.g., Chef and Puppet) for developing infrastructure code that should be developed and managed using the same rigor and tools as application code. We've stated in previous blogs that a team needs to plan and track everything as well as version everything. Infrastructure as Code and agile development tools provides teams with the ability to do just that. New technologies such as <a href="http://www.opscode.com/chef/">Chef</a> and <a href="http://puppetlabs.com/puppet/what-is-puppet/">Puppet</a> provide us with programming languages to develop and apply infrastructure configurations using the same development best practices (modular, self-documenting, test-driven) as application code. Tools such as <a href="https://jazz.net/products/smartcloud-continuous-delivery/">IBM SmartCloud Continuous Delivery</a> embrace and promote Infrastructure as Code development best practices.
</p>
<p>
Just as an Application Developer develops application code, an Infrastructure Developer develops Infrastructure Code. It's that simple. What we hear from many customers is &quot;Where do I find these Infrastructure Developers?&quot; The good news is that most companies already have folks that can fill this new role. What I have found is that the role will be filled most likely by existing Infrastructure Specialists or Application Developers. Look for Infrastructure Specialists that are willing to learn and especially any that have a development background. An Infrastructure Specialist generally will not be successful if thrown into the new role without some training. You should expect to train an Infrastructure Specialist to be an Infrastructure Developer by
</p><ul>
<li>Teaching basic agile development practices</li>
<li>Teaching of new automation technologies such as Chef or Puppet</li>
<li>Teaching the use of agile development tools (e.g., IDE and SCM)</li>
</ul><div><br /></div>
Pairing an Infrastructure Specialist with an Application Developer is a great way to produce an Infrastructure Developer. As I pointed out, it is also possible that the Application Developer becomes an Infrastructure Developer if they have the ability and desire to gain enough operational skills to develop the necessary automation configuration code. However, pairing the two roles together is a good approach to produce a person (or two) that has the skills to develop high quality infrastructure code. There is a whole discussion about changing team dynamics that we will save for another blog post.<p>
</p><p>
In closing, DevOps is a major driver of change and process improvement within an organization. While change is scary, you have to ask yourself <b>&quot;What Would You Do If You Weren't Afraid?&quot;</b> as Haw does within the book. Sometimes change is good and absolutely necessary.
</p></div><b>
</b>
Everyone is painfully aware that as technologies improve and evolve it becomes harder to deliver new features with quality to demanding customers. With new social and mobile applications customers have become trained to having their requests fulfilled within...1011893urn:lsid:ibm.com:blogs:entries-f0c7afc6-81fd-40d8-a7ae-0775c21390bbEnterprise DevOps2014-12-04T04:27:33-05:00urn:lsid:ibm.com:blogs:entry-8ee74714-6388-4451-8972-bad09d137385Wisdom from Mark Imbriaco @ the Triangle Meetup for DevOpsmdelder120000CYNEactivefalseComment EntriesLikestrue2012-07-19T17:12:00-04:002012-07-20T07:35:40-04:00
<p><a '="" href="https://www.ibm.com/developerworks/mydeveloperworks/blogs/devops/resource/BLOGS_UPLOADED_IMAGES/Collaboration.png
" target="_blank"><img alt="image" src="https://dw1.s81c.com/developerworks/mydeveloperworks/blogs/devops/resource/BLOGS_UPLOADED_IMAGES/Collaboration.png" style=" width:200px; display:block; margin: 1em 1em 0pt 0pt; float: left; position:relative;" /></a> If you haven't heard about the <a href="http://www.meetup.com/Triangle-DevOps/">Triangle Meetup for DevOps</a>, it's time to do some research and get involved. Several of us from the IBM DevOps Team were fortunate enough to attend the Meetup last night. Mark Imbriaco stepped up to share some wisdom from his experience in the DevOps space. Mark was originally a sysadmin at 37signals, then
was in operations at Heroku before becoming VP of Technical Operations
for <a href="http://tech.livingsocial.com/">LivingSocial</a>.</p>
<p>Mark focused a lot on the ratio of Developers to Operators; originally
at LivingSocial, it was in the range of 50:1 (100 developers, 2
operators). He believes a better ratio is closer to 8:1. Ultimately, the
smaller an operations team is, the more defensive it has to be and
often is consumed by fighting more fires than rolling out innovative new
applications. Mark also expressed that his philosophy was it's better
to be innovative and down from time to time than to be constantly up and
stifle innovation. He described the goals of operations as availability
and efficiency, where efficiency was about making it easier and faster
to deploy new applications.</p>
<p>
The importance of monitoring came up several times as well. At
LivingSocial, they divide the monitoring rules and notifications into two
sets: developers are notified when an application failure is detected,
and operators are notified when a systematic failure such as a database
outage is detected. The applications also embedded a configuration file
that knows how to configure the monitoring for certain kinds of things,
so that monitoring becomes a part of the application DNA. In some cases,
both developers and operators are notified -- but Mark indicated that
more often than not it's the application layer which detects a problem
and notifies the developer. It was interesting to me because I've
recently heard that mantra in other conversations with customers: developers can roll out whatever new innovative technologies that they
want to use, so long as they own the pager. The flexibility of
technologies used is a markedly different approach from when Mark
arrived to the operations team at LivingSocial. Originally, there were
specific supported versions and software (such as 1 version of ruby, 2
versions of rails, and all database access was done in MySQL).</p>
<p>
Mark also talked a lot about putting data into the cloud; I've heard
other customers express hesitation at this, but he made a good point --
physical hardware fails just like virtual machines. If you have to
account for redundancy and backup for physical hardware, why wouldn't
you do it in a cloud environment as well? He also felt that the I/O
bottleneck is often the biggest factor in application response times,
and that it was solvable with money -- just ensure ever machine has 2 x
10Gbit NICs and 8+ SSDs. Then all storage gets dramatically improved
responsiveness, which benefits the whole application.</p>
<p>
Mark gave us a good overview of LivingSocial's approach to Platform as a
Service (PaaS), which was influenced by his experience at Heroku. Like
all good projects, Mark said the first thing they did was come up with a
good name -- AirSpace. All other naming is derived from that metaphor.
When changes are delivered to Git, they have a post-commit listener
which triggers behavior in a component called <b>packer</b>
which produces &quot;cargo&quot;. The &quot;cargo&quot; is then placed in a &quot;cargohold&quot; and
awaits distribution by the ATC (Air Traffic Controller). Another
component, carousel, knows which bits of cargo are associated with which
applications. What I found very interesting was that they keep a set of
base machines up (&quot;autopilots&quot;) which watch for applications which need
to be deployed. Their &quot;airspace&quot; command can take cargo from the
cargohold and put it in a queue. Then the autopilots (pre-provisioned
virtual images that conform to their base image), pick up work off of
the queue. The first instance to get the cargo from the queue will
configure itself with the application. When the running application is
no longer needed (retired, fails, etc), the autopilot removes itself and
frees up resources for new clean autopilots to run.</p>
<p>
This approach allows them to quickly deliver changes to a running
environment and promotes a philosophy that every component of the PaaS
is simple and serves a specific purpose -- much like the UNIX command
philosophy. The usage of queues is prevalent to allow for easy
scalability when needed.</p>
<p>
They also use hardware-based routing to shuffle traffic to autopilots
which host applications, so they can easily route a percentage of the
traffic to new autopilots when updates are rolled out. And if problems
occur, the previous instances are still running, so rollback is simply
an adjustment to the routing pattern.</p>
<p>
Our own Chuck Brant proposed that the name of a yet to be component to
control that kind of logic be named &quot;Control Tower&quot;, and the name seemed
to stick. Way to go Chuck! :)</p>
<div>The
turn out was really good (35-40) and had some recognizable names in the
DevOps space like <a href="http://www.amazon.com/Release-It-Production-Ready-Pragmatic-Programmers/dp/0978739213">the author of Release It!</a>. The Meetup group is now organized by <a href="http://www.meetup.com/Triangle-DevOps/members/7368374/">Mark Mzyk</a> of Opscode and he is aiming for a cadence of the third Wednesday of each month. So come on out and get engaged!<br />
<br />All in all, it was a great session and really demonstrates the interest in this area (both topically and geographically). Many thanks to Mark Mzyk for organizing the event and Mark Imbriaco for making time to come and talk to the group. Also, many thanks to <a href="http://webassign.net/">WebAssign</a> for hosting (now I'm a bit jealous of their offices ..).</div><div> </div><div> </div><div>* Image <a href="http://office.microsoft.com/en-us/images/results.aspx?qu=people#ai:MC900174351|mt:1|">originated</a> from the Office Clip Art Gallery <br /></div>
If you haven't heard about the Triangle Meetup for DevOps , it's time to do some research and get involved. Several of us from the IBM DevOps Team were fortunate enough to attend the Meetup last night. Mark Imbriaco stepped up to share some wisdom from his...103747urn:lsid:ibm.com:blogs:entries-f0c7afc6-81fd-40d8-a7ae-0775c21390bbEnterprise DevOps2014-12-04T04:27:33-05:00urn:lsid:ibm.com:blogs:entry-4e9c85b4-4f64-4ed4-be78-c122b0530daa12 Steps to Better DevOpsmdelder120000CYNEactivefalseComment EntriesLikestrue2012-06-15T16:52:46-04:002012-06-15T17:00:32-04:00
<div style="font-family: calibri, helvetica; font-size: 12pt">
<p>
<a href="https://www.ibm.com/developerworks/mydeveloperworks/blogs/devops/resource/BLOGS_UPLOADED_IMAGES/Whiteboardwithsteps.png" target="_blank"><img alt="image" src="https://dw1.s81c.com/developerworks/mydeveloperworks/blogs/devops/resource/BLOGS_UPLOADED_IMAGES/Whiteboardwithsteps.png" style="display:block; margin: 1em 1em 0pt 0pt; float: left; position:relative;" /></a>For those that follow <a href="http://www.joelonsoftware.com/"><span class="s1">Joel on Software</span></a>, you may be familiar with his blog entry &quot;<a href="http://www.joelonsoftware.com/articles/fog0000000043.html"><span class="s1">The Joel Test: 12 Steps to Better Code</span></a>&quot;. While authored way back in 2000, its content and statements are still relevant today. As people tried to understand Agile, the 12-step test provided a simple litmus test of concrete actions to help improve your over all software delivery. </p>
<p>Roll forward nearly a decade where DevOps is seeking to drive similar improvements to how operational aspects of software are delivered, managed, and maintained over time. Many people have explained their view of DevOps and what it takes to &quot;live DevOps&quot;. I'd like to propose a similar set of concrete actions like Joel did for software to help explain my view of this topic. </p>
<p>Ultimately, DevOps is about trust. Trust between the Business &amp; Development. Trust between Development and Operations. Trust among these groups enables the organization as a whole to be more agile and to better manage risk. </p>
<p>So how do we build trust? Consider the following 12 steps:</p>
<br />
</div>
<div style="border: 3px orange solid; font-size: 12pt; font-family: helvetica, arial; line-height: 14pt">
<a href="https://www.ibm.com/developerworks/mydeveloperworks/blogs/devops/resource/BLOGS_UPLOADED_IMAGES/12StepstoBetterDevOps.png" target="_blank"><img alt="Clipboard image" src="https://dw1.s81c.com/developerworks/mydeveloperworks/blogs/devops/resource/BLOGS_UPLOADED_IMAGES/12StepstoBetterDevOps.png" style="display:block; margin: 1em 1em 0pt 0pt; float: right; position:relative;" /></a>
<ol>
<li>Do your developers and operators communicate the production realities and the application's requirements?</li><li>Do you version deployment configuration and scripts along with your source code?</li>
<li>Do you have patterns for platforms and applications, designed jointly by development and operations?</li>
<li>Can your developers launch and destroy production-like environments from those patterns?</li>
<li>Are your patterns based on reusable deployment configuration scripts?</li>
<li>Can you deploy an environment (platform and application) in one step?</li>
<li>Do you deploy your applications daily into production-like environments and verify them?</li>
<li>Do you link bugs and work items to changes in the application and configuration?</li>
<li>Do you associate tickets for production issues with relevant bugs opened for development to fix?</li>
<li>Do you have automated tests to validate your application and platform function and characteristics?</li>
<li>Do you monitor software against expectations after deploying your application?</li>
<li>Do you have a delivery pipeline exposed through a summary dashboard to assess delivery velocity?</li>
</ol>
</div>
<div style="font-family: calibri, helvetica; font-size: 12pt">
<br />
<p>
These steps are inspired by Joel's approach to explaining a new discipline, but follow the mantras that we've already recommended. Let's talk a bit more about these steps and I'll flag the association with the mantras in each case. You can reach more about the mantras in our <a href="https://www.ibm.com/developerworks/mydeveloperworks/blogs/invisiblethread/entry/6-ways-for-enterprises-to-adopt-devops">first blog entry on the Invisible Thread</a>.
</p>
<br />
<h3>1. Do your developers and operators communicate the production realities and the application's requirements? </h3>
<h4>[<b>Track and Plan</b> <i>everything</i>]</h4>
<br />
<p>
Almost every customer we've ever talked to cites the lack of effective communication as a barrier to accelerated delivery. Often development and operations teams work in silos because that's how the executive hierarchy is configured. Each group is measured against a different set of metrics: change vs. stability. However, to ensure smooth delivery, it is absolutely imperative to establish how the needs of the application will be supported by the final production environment early in the process. The communication might be as lightweight as a face to face meeting where all concerns are discussed, a template to understand what capabilities are needed and provided, or something more detailed like a topology diagram. Regardless of the format, the information must be communicated early.
</p>
<br /><h3>2. Do you version deployment configuration and scripts along with your source code? </h3>
<h4>[<b>Version</b> <i>everything</i>]</h4>
<br />
<p> Often, specialists are already creating deployment scripts today; bash, perl, python, wsadmin, ruby, chef, puppet are all examples of assets which help stand up environments. But for whatever reason, these assets aren't generally handled like the same .java, .jsp, .html or .ddl assets which make up the business logic of the application. <b>Step 2 says that deployment configuration and script assets should be treated like valuable content just like the application source code.</b>
</p>
<p>
The idea is that the automation scripts and configuration files which have been left by the wayside as middleware evolved are brought back into the fold and considered part of the overall solution. Incorporating these artifacts into the same version control systems that have proven valuable for application source code means that you can more easily view and compare changes from prior deployments. If you're deploying the system completely through automation, it may also mean that rolling back a new deployment means simply re-applying the last approved version of the automation.
</p>
<br />
<h3>3. Do you have patterns for platforms and applications, designed jointly by development and operations? </h3>
<h3>4. Can your developers launch and destroy production-like environments from those patterns?</h3>
<h4>[<b>Track and Plan</b> <i>everything</i>]</h4>
<br />
<p>Steps 3 and 4 are focused on enabling production-like systems to be leveraged earlier in the development process. Standard application and platform patterns are decided with collaboration between development and operations. Those patterns are then used by developers in an on demand form when they need to iterate quickly on changes for the application in their own isolated environment. When changes are ready for delivery, the build and deploy process should use the same patterns to deploy and verify each new build. The net is that both development and the continuous delivery process are using production-like patterns to verify their approach far earlier in the delivery process than what you may be used to today.
</p>
<br />
<h3>5. Are your patterns based on reusable deployment configuration scripts? </h3>
<h3>6. Can you deploy an environment (platform and application) in one step? </h3>
<h3>7. Do you deploy your applications daily into production-like environments and verify them? </h3>
<h4>[<b>Automate</b> <i>everything</i>]</h4>
<br />
<p>
Steps 5, 6, and 7 each deal with automation -- but unlike traditional automation approaches, DevOps generally uses automation technologies which have file-based persistence, which are declarative rather than imperative, and which are applied, applied, and applied over and over again. Many organizations have already bought into the value of automation, but often focus on automation above the platform layer -- to deploy the application into an existing platform. DevOps takes the end goal a step further to stress automation to create the entire solution -- from the platforms all the way to the end user.
</p>
<p>DevOps asks the same kind of questions about deployments that agile software asked about builds. The ability to do a build in one step enabled us to perform builds more frequently ensuring that everything compiles. Similarly, being able to do a deployment in one step enables more frequent deployments. If a problem is introduced, you want to find it early and fail fast.
</p>
<p>
There's a subtly here that may be overlooked and I want to call your attention to it. If you're providing production like environments to validate the application, you're also able to validate the platforms that are supporting the applications. Hence any new platform updates that you plan to roll out feed into the pipeline just like application builds. If your middleware platform needs to be updated, you would roll that change out first early in a development stage of your pipeline. Just as application artifacts are graduated through the pipeline as they pass their verifications, so are changes to the infrastructure components like your middleware. Treating application and infrastructure components like equal citizens means that there isn't a special exception process for one kind of change or another -- all changes go through the same journey together in harmony.
</p>
<p>
Ultimately, steps 5-7 hint at a role transition that occurs in DevOps where operations engineers no longer act as administrators but more as content creators -- as <b>infrastructure developers</b>. Like software developers, infrastructure developers create automation to provision and maintain the infrastructure, platforms, and applications in each stage of your pipeline.
</p>
<br />
<h3>8. Do you link bugs and work items to changes in the application and configuration? </h3>
<h3>9. Do you associate tickets for production issues with relevant bugs opened for development to fix? </h3>
<h4>[<b>Track and Plan</b> <i>everything</i>]</h4>
<br />
<p>Steps 8 and 9 talk about how changes are tracked. Joel asked you if you had a bug database. We're asking if you link bugs or work items directly to the affected changes in your version control. It's important to have this level of traceability so you can identify why a particular change was introduced and ideally what related files were touched. If you want to see what this looks like, take a look at <a href="jazz.net">jazz.net</a>. And since you're tracking changes to your deployment configuration and scripts (as in Step 2), that means that changes to those artifacts also go through the bug database and are then deployed and tested just like application code.
</p>
<p>No matter how much some of us developers would like to think the real work is done once an application reaches production, it's not! When problems happen in production, there's generally an existing process for tracking incidents. We're suggesting that whenever incidents are encountered, an incident ticket should be opened and linked directly to defects in either the software or configuration layer, ensuring traceability from end to end. The bug or work item enables you to track when a fix is released to the application or configuration and know when the ticket can be closed. Knowing what the incident looked like in production means you can also beef up test cases so that a regression isn't introduced in the future. It doesn't matter if the root cause is in the business logic or an invalid datasource configuration, the changes should be treated and managed in the same way. Since bugs are linked to changes (Step 8), you'll know what had to change to fix the incident.
</p>
<br />
<h3>10. Do you have automated tests to validate your application and platform function and characteristics? </h3>
<h4>[<b>Test</b> <i>everything</i>]</h4>
<br />
<p>
The goal here is to ensure that your provisioning process is meeting the expectations of stakeholders including development, quality assurance, and operations. Other stakeholders like performance and security testing may also play a role. Software development did this first with compilation. It ensured that all of your source code could be translated into a machine readable format. Errors were quickly reported as part of the build process. Then agile promoted the notion of incorporating unit tests, static analysis, and other security compliance scans. DevOps expands that notion to also testing the deployed software and its supporting platforms. Steps 7 and 10 ensures that you actually use it regularly!
</p>
<br />
<h3>11. Do you monitor software against expectations after deploying your application? </h3>
<h4>[<b>Audit and Monitor</b> <i>everything</i>]</h4>
<br />
<p>
Most production systems already have some level of monitoring in use today. Exposing production-like patterns and environments earlier should mean that monitoring capabilities are available to developers. Hence, developers and operators have the opportunity to verify that application code is being written to be easy to monitor. Just like knowing what an incident looks like can help you beef up test cases, knowing what kind of information is (or isn't) coming from an application's monitoring capabilities will help you understand how to provide better feedback in production. Like Steps 7 and 10 are about providing continuous feedback about the function of the application, Step 11 is about validating expectations for performance and reliability through monitoring early in the process.
</p>
<br />
<h3>12. Do you have a delivery pipeline exposed through a summary dashboard to assess delivery velocity?</h3>
<h4>[<b>Dashboard</b> <i>everything</i>]</h4>
<br />
<p>
Almost all organizations have a loosely defined, loosely coupled notion of delivery pipeline. Establishing a common understanding of what stages an application must pass through on the way to production ensures that hand offs are predictable and tracked to ensure accountability. Beyond that, providing progress reports about applications and their location through the pipeline -- from inception to happy end user -- is critical to ensure that you're constantly improving the overall delivery response time.
</p>
<p>
A lot of this process also means establishing the right metrics for your organization at a higher level and ensuring that those metrics can be tracked. An example metric might include something like &quot;how long does it take to release a no-change version of my application?&quot; That is, if you don't change a single line of source code, how quickly could you get the current version rolled out into production (starting in development)? Often (surprisingly) this time is non-zero. A lot of it may include manual configuration and intervention which limits how quickly it can be done. Again, focusing on automation from barebones to happy user means that <b>you can increase your delivery velocity with managed risk</b>.
</p>
<br />
<p>
</p><p>In closing, while this article is by no means fully prescriptive of how to transform your organization, I hope it has at least inspired some thoughts about how you might begin incremental adoption of the techniques encouraged by DevOps.</p>
</div>
<br />
<div style="ont-family: calibri, helvetica; font-size: 12pt">
<p>I would like to thank Bill Mitlehner and Jeff Imholz for their contribution to the ideas expressed in this article. </p>
</div>
For those that follow Joel on Software , you may be familiar with his blog entry &quot; The Joel Test: 12 Steps to Better Code &quot;. While authored way back in 2000, its content and statements are still relevant today. As people tried to understand Agile,...2013413urn:lsid:ibm.com:blogs:entries-f0c7afc6-81fd-40d8-a7ae-0775c21390bbEnterprise DevOps2014-12-04T04:27:33-05:00urn:lsid:ibm.com:blogs:entry-c197fa77-d7ca-46a2-8dcc-bd31b4ea2a1aDevOps at IBM Innovate 2012 next weekDanBerg0600006G7XactivefalseComment EntriesLikestrue2012-06-01T21:53:36-04:002012-06-01T21:53:36-04:00
<a '="" href="https://www.ibm.com/developerworks/mydeveloperworks/blogs/devops/resource/BLOGS_UPLOADED_IMAGES/ScreenShot2012-06-01at3.32.47PM.png" target="_blank"><img alt="image" src="https://dw1.s81c.com/developerworks/mydeveloperworks/blogs/devops/resource/BLOGS_UPLOADED_IMAGES/ScreenShot2012-06-01at3.32.47PM.png" style=" display:block; margin: 0 auto;text-align: center; position:relative;" /></a> <div> </div><div>As conference season continues we are now coming upon <a href="http://www-01.ibm.com/software/rational/innovate/">IBM's Innovate 2012</a> conference held in sunny Orlando FL at the Walt Disney World Swan and Dolphin Resort. If you will be attending the conference this year please check out some of our <b>DevOps</b> specific sessions where you can meet several of the authors of this blog such as myself, Michael Elder, and Steve Abrams. We have a list of the <b><a href="http://lanyrd.com/search/?conference=cgzcf&amp;q=DevOps">DevOps specific sessions</a> </b>at Lanyard.com.</div><div> </div><div>At the Innovate conference there will be many demonstrations showing integrated tools and capabilities in support of DevOps and more generally Application Lifecycle Management. We will be showing some of the demos during the main tent keynotes on Monday and you may get up close and personal with the demons downstairs in our Integration Center. In the Integration Center we will have several pedestals which will be linked together on a shared network with linked demonstrations using IBM and open source tooling.</div><div> </div><div>For all of you old folks like myself you will enjoy the entertainment on Wednesday where Foreigner will be performing. For the youngins we have a fun evening with the fish at Sea World. </div><div> </div><div>See you there! </div><div> </div><a '="" href="https://www.ibm.com/developerworks/mydeveloperworks/blogs/devops/resource/BLOGS_UPLOADED_IMAGES/ScreenShot2012-06-01at3.46.23PM.png
" target="_blank"><img alt="image" src="https://dw1.s81c.com/developerworks/mydeveloperworks/blogs/devops/resource/BLOGS_UPLOADED_IMAGES/ScreenShot2012-06-01at3.46.23PM.png" style=" display:block; margin: 1em 1em 0pt 0pt; float: left; position:relative;" /></a> <div> </div><div> </div><div> </div><a '="" href="http://seaworldparks.com/_assets/img/logo/seaworld.png" target="_blank"><img alt="image" src="http://seaworldparks.com/_assets/img/logo/seaworld.png" style=" display:block; margin: 1em 1em 0pt 0pt; float: left; position:relative;" /></a>
As conference season continues we are now coming upon IBM's Innovate 2012 conference held in sunny Orlando FL at the Walt Disney World Swan and Dolphin Resort. If you will be attending the conference this year please check out some of our DevOps specific...103531urn:lsid:ibm.com:blogs:entries-f0c7afc6-81fd-40d8-a7ae-0775c21390bbEnterprise DevOps2014-12-04T04:27:33-05:00urn:lsid:ibm.com:blogs:entry-74cb7153-7875-458d-b558-9f9902e3886eAre you treating your servers like snowflakes or rubber stamps?ann_marie_9906000073UAactivefalseComment EntriesLikestrue2012-05-23T11:02:25-04:002012-06-12T08:43:33-04:00<div><a href="https://www.ibm.com/developerworks/mydeveloperworks/blogs/devops/resource/BLOGS_UPLOADED_IMAGES/2Snowflakes.jpg" target="_blank"><img alt="image" src="https://dw1.s81c.com/developerworks/mydeveloperworks/blogs/devops/resource/BLOGS_UPLOADED_IMAGES/2Snowflakes.jpg" style=" width:100px; display:block; margin: 1em 1em 0pt 0pt; float: left; position:relative;" /></a> I was inspired by this entertaining article by Alex Tatiyants: <a href="http://tatiyants.com/devops-is-ruining-my-craft/?replytocom=4818">DevOps is Ruining My Craft</a>.<br /><br /><p /><p>A favorite analogy in the DevOps community is that the “old style” of IT server management, where people can make manual changes to their servers, leads to production servers that are unique and precious, like snowflakes. If you don’t completely automate the configuration of your servers, your chances of re-creating the exact same server twice are nearly zero, just as no two snowflakes are alike. And because you can never re-create a production server, you must do everything in your power to protect it from changes that can break it.</p><div> </div><p>The problem with this approach is that it creates an adversarial relationship between developers, who want to change the servers often to release new features, and operations professionals, who want to keep the servers running and safe. Operations teams tend to “lock down” the production servers and only allow changes to them on rare occasions. This makes business-critical software less agile and more difficult to change. </p><div> </div></div> <div>
<p><a href="https://www.ibm.com/developerworks/mydeveloperworks/blogs/devops/resource/BLOGS_UPLOADED_IMAGES/9Snowflakes.jpg" target="_blank"><img alt="image" src="https://dw1.s81c.com/developerworks/mydeveloperworks/blogs/devops/resource/BLOGS_UPLOADED_IMAGES/9Snowflakes.jpg" style=" width:100px; display:block; margin: 1em 1em 0pt 0pt; float: left; position:relative;" /></a> So what’s the alternative to servers as snowflakes? Servers as rubber stamps! We advocate automating everything, so that your servers can be re-created on demand. Do you want another web server? Ca-chunk, here you go. Do you want another web application server? Ca-chunk, no problem. </p><div> </div><p>Creating a new server for each release of new code, and replacing the old server with the new one, simplifies “rolling deployments” into production and other techniques that DevOps advocates recommend. </p><div> </div><div>Do you want to add a new web application to your site? Stamp out a new web application server with the new application on it, test the new website in a staging environment, re-configure the tested server so it’s available in your production server pool, and then redirect your web traffic to go to the new server instead of the old one. </div><div> </div><p>Cloud computing is the enabling technology that makes “rubber stamp” servers easy. While you can automate the configuration of standalone servers, it’s dramatically simpler to automatically create and configure new servers in a cloud for every code change. When you start with a clean virtual machine image every time, the new systems that you create will be almost identical to one another when they start up. When you then automate every step of the configuration process with infrastructure automation code, you can be sure that your systems will be configured in a repeatable way.</p><div> </div>
<p>These techniques have already been put into practice by other DevOps leaders, including Etsy, Facebook, and Flickr. At IBM we’re developing new tools and integrations between existing tools, to make DevOps principles and practices easier for our enterprise customers to adopt. One such solution is <a href="http://www-01.ibm.com/software/rational/devops/">IBM SmartCloud Continuous Delivery</a>, which we’re developing now. </p><div> </div></div><p>I work on the IBM SmartCloud Continuous Delivery development team, and we are using SmartCloud Continuous Delivery to build SmartCloud Continuous Delivery. For example, we use Rational Team Concert with our Continuous Delivery plug-ins as our development environment, and we use our Continuous Delivery build definitions to automatically create new test servers in the cloud every time we deliver a code change.</p><div> </div><div>IBM’s Virtual System Patterns make infrastructure automation even easier. Rather than starting with virtual machine images, we start with pre-configured patterns that already include the prerequisite software for our application. These patterns are available with IBM Workload Deployer today, and they also will be available with the new IBM PureApplication Systems and the next version of SmartCloud Provisioning. </div><div> </div><p>You can think about a Virtual System Pattern like a rubber stamp for virtual systems. For example, if your production system includes multiple WebSphere Application Servers and DB2 servers, you can use this Virtual System Pattern as a starting point:</p><div> </div><div><a href="https://www.ibm.com/developerworks/mydeveloperworks/blogs/devops/resource/BLOGS_UPLOADED_IMAGES/DevOpsDB2WASCluster.PNG
" target="_blank"><img alt="image" src="https://dw1.s81c.com/developerworks/mydeveloperworks/blogs/devops/resource/BLOGS_UPLOADED_IMAGES/DevOpsDB2WASCluster.PNG" /></a> <br /></div><div><br /></div><div>There’s a lot of detail in this screenshot, but here are some of the more interesting things that this Virtual System Pattern handles for us:</div><ul><li>When you deploy this pattern, it will automatically deploy, start, and configure all of the systems for you.</li><li>There are different types of servers here, including the Deployment Manager and Custom Nodes (for WebSphere Application Server), HTTP servers, and DB2 servers running in Primary and Standby modes. </li><li>By default this Virtual System Pattern will create one of each server and two Custom Node servers, but those numbers are configurable. If you want 5 Custom Nodes and 3 HTTP servers, you can change those values at deployment. </li><li>The Virtual Machine images have been optimized, and additional tuning can be done at deployment, such as the “JVM tuning” on the Custom Nodes.</li><li>The servers have been configured to work together, such as the “Cluster configuration” on the Deployment Manager.</li><li>The servers have been secured and patched using the “iwd_VMCompliance” script package that our operations team automatically adds to every pattern.</li><li>The “DevOps Bootstrap” script package is the hook that enables our Continuous Delivery process. When that script runs, it will run our infrastructure automation code to finish configuring the servers, install our new application, and start it.</li></ul><p /><p>Starting with a Virtual System Pattern is useful because it saves developers from having to worry about everything listed above. Also, those systems have already been optimized for the best performance, reliability, availability, and security by someone with real-world operations experience. Finally, using a pre-defined pattern reduces the number of different configurations that the development and operations teams need to support. We don’t even need to write installers for applications that only need to run in our cloud environment; we just write automation code that assumes we’re creating a brand new server, and we can make assumptions about what’s already installed and configured on the server. That saves us time that we can use to do more important things.</p><div> </div><p>Creating and configuring new servers in the cloud is also orders of magnitude faster than the same activities outside a cloud environment. Most of my team’s test systems (which usually include 1-2 VMs) are up and running within 15-30 minutes after a developer delivers new code. That includes building the application and infrastructure automation code, publishing it to the software library, provisioning and starting multiple VMs, installing and configuring the prerequisite software (like the application server and database) on all of the VMs, installing and configuring our application on the correct VMs, starting all of the services, and even testing the running servers! We can do several of these deployments in parallel as well, and it’s not unusual for my development team to run through this entire automated process several times every day. And when we’re done with test systems, we can automatically delete them.</p><div> </div><p>There will always be a need for some long-running production servers, and some applications don’t lend themselves to this type of deployment as well as others. However, creating new virtual systems for every code change is ideal for development and test teams, and that’s why we started with development and test tooling for SmartCloud Continuous Delivery. We’re currently working toward our first betas for SmartCloud Continuous Delivery. Over time we hope to extend our DevOps tooling support to enable more extensive operational testing, deployments into production, and incident management.</p><div> </div><p>We’ve seen how SmartCloud Continuous Delivery, along with Virtual System Patterns, can help create and test new virtual systems automatically. SmartCloud Continuous Delivery is designed to get rid of the bottleneck caused by waiting for someone to set up new test servers. It allows us to test a running multi-server system after every code delivery, and when we do that, it’s much easier to catch bugs and fix them earlier. Finally, when operations teams are confident that new code has been tested well, they can allow developers to release changes into production more often. This allows businesses to be more agile and react to change more quickly.</p><div> </div><p>Goodbye, snowflakes. Hello, rubber stamps!<br /></p>
I was inspired by this entertaining article by Alex Tatiyants: DevOps is Ruining My Craft . A favorite analogy in the DevOps community is that the “old style” of IT server management, where people can make manual changes to their servers, leads to production...209612urn:lsid:ibm.com:blogs:entries-f0c7afc6-81fd-40d8-a7ae-0775c21390bbEnterprise DevOps2014-12-04T04:27:33-05:00urn:lsid:ibm.com:blogs:entry-98556d97-a1c9-4313-9798-d8a0f4b55966DevOps at Impact 2012DanBerg0600006G7XactivefalseComment EntriesLikestrue2012-05-14T16:10:15-04:002012-05-14T21:17:58-04:00
<title>DevOps</title>
<div>I and many of my fellow cloud and <b>DevOps</b> colleagues attended and presented DevOps specific sessions at the recent <b>IBM Impact 2012</b> conference in sunny Las Vegas. The conference had over 8,500 participants flooding the Venetian. The key technology trends discussed at the conference were:</div><div><ul><li><b>Cloud</b></li><li><b>Mobile</b></li><li><b>BPM</b><img alt="PureApplication" src="https://dw1.s81c.com/developerworks/mydeveloperworks/blogs/devops/resource/BLOGS_UPLOADED_IMAGES/pureApplication.jpg" style="display: block; margin-top: 1em; margin-right: 0pt; margin-bottom: 0pt; margin-left: 1em; float: right; position: relative; " /></li><li><b>DevOps (our favorite)</b><br /></li></ul><div>One of the biggest announcements at the conference was the announcement of the new <a href="http://www.ibm.com/ibm/puresystems/us/en/index.html#tab:overview/subtab:default">IBM PureSystems</a> which include IBM PureFlex and PureApplication. These are IBM's new workload optimized cloud environments providing dramatic effeciencies for customers who are looking to adopt a private cloud platform. </div><div> </div><div>As we saw last year, Mobile continued to be a hot topic as many more customers seemed to be exploring ways to build native and hybrid cloud applications. IBM's <a href="http://www.worklight.com/">Worklight </a>tools and runtime sessions were in high demand as customers feel the pain of having to support multiple mobile platforms. Worklight provides capabilities to build a single application that can be natively hosted in multiple mobile platforms. </div><div> </div><div>What we learned while at the Impact conference is that as more customers move to adopt <b>Cloud</b> (and <b>Agile</b> development practices) there is a greater desire for enterprises to learn more about DevOps and how aspects such as <b>Continuous Delivery</b> can improve their ability to delivery faster business results with higher quality. We also heard many customers that are interested in adopting Mobile have found that Mobile development requires faster delivery times. Plus Mobile deployments are generally more complex than a traditional web application. For these reasons alone customers have begun to understand that they must adopt DevOps practices and continuous delivery to have any hope of being able to rapidly deliver changes for mobile applications. For example I conducted a lightning talk at the Developers Mini Main Tent: &quot;The New Development Reality&quot; where I spoke about the DevOps practice of capturing Infrastructure as Code and managing and building the code using Agile practices and tools. You can read more about the Developers Mini Main Tent at the <a href="https://www-304.ibm.com/connections/blogs/aim/entry/impact_session_notes_developers_mini_main_tent_the_new_development_reality1?lang=en_us">IBM Impact blog</a>.</div><div> </div><div>As more customers begin to realize that they have to adopt DevOps methodologies and tools we see them quickly hone in on the fact that the cultural changes will be necessary and will be difficult. Thus we are being asked &quot;How should our organization change to adopt DevOps?&quot; As everyone knows the greatest challenge when adopting DevOps is dealing with the cultural changes that must be made. Another challenge is how to communicate the value of DevOps to executives which is very important because you need executive buy-in to be able to make the cultural changes. We'll be exploring different cultural change scenarios and best practices in future blog posts.</div><div> </div><div><a href="http://www-01.ibm.com/software/rational/innovate/">IBM Innovate 2012</a> is right around the corner. I hope to see you there because we will be performing some very interesting integrated continuous delivery demonstrations. </div><br /></div><div>
</div>
DevOps I and many of my fellow cloud and DevOps colleagues attended and presented DevOps specific sessions at the recent IBM Impact 2012 conference in sunny Las Vegas. The conference had over 8,500 participants flooding the Venetian. The key technology trends...103581urn:lsid:ibm.com:blogs:entries-f0c7afc6-81fd-40d8-a7ae-0775c21390bbEnterprise DevOps2014-12-04T04:27:33-05:00urn:lsid:ibm.com:blogs:entry-9d91c4f5-ce5b-4f86-b0ca-e2e6773cf0dbDevopsdays - Austin 2012jryding270000Y99RactivefalseComment EntriesLikestrue2012-05-04T11:19:53-04:002012-05-15T07:38:24-04:00
<div>In early April, a couple members of the IBM DevOps team went to Austin, Texas to attend the <a href="http://devopsdays.org/">Devopsdays</a> Austin 2012 conference. This was a conference that is put on by members of the DevOps community to help get people from different organizations together to share ideas and learn from each other. We met a bunch of smart people and learned a lot about how some teams have implemented DevOps practices in their orgnanizations. Today, I want to talk about a couple topics that the IBM DevOps team has been researching and were important themes at the conference.</div><div><br /></div><div><b>The Importance of Culture</b></div><div><br /></div><div>The adoption of DevOps practices requires looking at two components in delivering software: technology and culture. The technical component addresses the practice of focusing on automating an application's deployment, incorporating version control, and using various tools to gain insight into how software is being built and deployed. The cultural aspect of adopting DevOps requires an organization to look at its processes of delivering software and figuring out how teams can move faster. As Steve <a href="https://www.ibm.com/developerworks/mydeveloperworks/blogs/devops/entry/welcome_to_the_enterprise_devops_blog3?lang=en">alluded to in his last post</a>, one of the challenges of adopting DevOps is that development cultures and operations cultures are different. To grossly oversimplify a complex topic, developers are generally focused on shipping new features quickly and operations is generally focused on system stability, performance, security, and other operational quality characteristics. To embrace DevOps, these two groups need to collaborate on a single goal: delivering on the needs of the business. The separate groups need to learn how to work with one another; they need to trust and respect the domain of expertise each group has. When problems do occur (which is inevitable when changing a complex system), blaming each other won't fix anything. Instead, the teams need to focus on the real issue: the problem itself. <a href="http://twitter.com/BOTCHAGALUPE">John Willis</a> put this best:</div><div><br /></div><div>&quot;When we go into the war room, the problem is the enemy.&quot;</div><div><br /></div><div>When issues in production do occur, working together as a single team that is solving a problem is the goal and learning how to address and/or prevent the problem in the future should be the outcome. The DevOps community is doing some amazing work around tooling that take advantage of cloud technologies but, much like the Agile movement, using these tools won't instantly save organizations from inefficient processes. Addressing these bottlenecks in application delivery and finding a balance between moving fast while maintaining proper governance is a significant part of getting an organization to adopt DevOps. </div><div><br /></div><div><b>Security in DevOps</b></div><div><br /></div><div>In the way that DevOps is evolving operations groups, the same is going to happen to security teams that do not collaborate well with development groups. Security teams are a lot like operations groups, both provide a domain of expertise and are required to protect the business from problems. Unfortunately, as <a href="http://twitter.com/kartar">James Turnbull</a> of <a href="http://puppetlabs.com/">Puppet Labs</a> puts it, security has emerged as the organization that tends to always say &quot;no&quot; due to fear of exposing the business to an external threat. This inevitably creates friction between security and the rest of the business: development thinks that the security group gets them in trouble and the business leaders think they have to move slow before introducing a radical change. These views of the security group needs to change, or else the development and business leaders will figure out a way to circumvent them.</div><div><br /></div><div>In the world of DevOps, security needs to change the same way operations is changing. Security people need to collaborate closer with development so that both groups understand the needs of one another. No one wants to allow the external threats affect the business, but few people have the knowledge to properly protect themselves. Giving security a seat at the project design table or embedding someone inside the development team will help greatly with breaking down these walls. James Turnbull and <a href="http://twitter.com/ngalbreath">Nick Galbreath</a> (<a href="http://www.etsy.com/">Etsy</a>) really hit the nail on the head by acknowledging that instead of security groups looking at themselves as the last gatekeepers to protecting the business, they need to evolve into consultants and knowledge experts that help deliver on the neesd of the business. With this view in place, these groups can help teach the business leaders and development teams what exactly needs to be done to help.</div><div><br /></div><div><b>Conclusion</b></div><div><br /></div><div>DevOps Days Austin was a great event full of smart people. We learned a lot from our time there. The aspect of changing an organizations culture to accommodate the efficient processes of DevOps is a significant topic. It's going to affect many groups and if the culture of collaborating across teams is not in place, no DevOps tool will help. We will be exploring the topic of culture more in future articles and invite other DevOps community members to provide their input.</div><div><br /></div><div>If you are interested in attending one of the many Devopsdays events occuring around the world this year, be sure to check out the [DevOps Days website](www.devopsdays.org). You can also view the recorded presentations from Devopsdays Austin 2012 <a href="http://www.ustream.tv/channel/devopsdays-austin-2012">online</a>.</div>
In early April, a couple members of the IBM DevOps team went to Austin, Texas to attend the Devopsdays Austin 2012 conference. This was a conference that is put on by members of the DevOps community to help get people from different organizations together to...104387urn:lsid:ibm.com:blogs:entries-f0c7afc6-81fd-40d8-a7ae-0775c21390bbEnterprise DevOps2014-12-04T04:27:33-05:00urn:lsid:ibm.com:blogs:entry-066ddcb7-ef6d-4f61-83a7-95ba6d7a6a88Welcome to the Enterprise DevOps BlogSteveAbrams270000YJ02activefalseComment EntriesLikestrue2012-04-26T16:23:17-04:002012-04-26T17:29:17-04:00
<!--[if gte mso 9]&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;xml&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;o:DocumentProperties&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;o:Template&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;Normal.dotm&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/o:Template&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;o:Revision&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;0&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/o:Revision&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;o:TotalTime&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;0&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/o:TotalTime&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;o:Pages&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;1&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/o:Pages&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;o:Words&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;655&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/o:Words&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;o:Characters&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;3738&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/o:Characters&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;o:Company&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;IBM&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/o:Company&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;o:Lines&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;31&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/o:Lines&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;o:Paragraphs&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;7&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/o:Paragraphs&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;o:CharactersWithSpaces&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;4590&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/o:CharactersWithSpaces&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;o:Version&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;12.0&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/o:Version&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/o:DocumentProperties&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;o:OfficeDocumentSettings&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;o:AllowPNG/&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/o:OfficeDocumentSettings&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/xml&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;![endif]--><!--[if gte mso 9]&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;xml&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;w:WordDocument&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;w:Zoom&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;0&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/w:Zoom&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;w:TrackMoves&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;false&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/w:TrackMoves&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;w:TrackFormatting/&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;w:PunctuationKerning/&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;w:DrawingGridHorizontalSpacing&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;18 pt&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/w:DrawingGridHorizontalSpacing&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;w:DrawingGridVerticalSpacing&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;18 pt&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/w:DrawingGridVerticalSpacing&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;w:DisplayHorizontalDrawingGridEvery&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;0&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/w:DisplayHorizontalDrawingGridEvery&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;w:DisplayVerticalDrawingGridEvery&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;0&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/w:DisplayVerticalDrawingGridEvery&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;w:ValidateAgainstSchemas/&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;w:SaveIfXMLInvalid&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;false&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/w:SaveIfXMLInvalid&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;w:IgnoreMixedContent&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;false&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/w:IgnoreMixedContent&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;w:AlwaysShowPlaceholderText&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;false&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/w:AlwaysShowPlaceholderText&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;w:Compatibility&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;w:BreakWrappedTables/&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;w:DontGrowAutofit/&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;w:DontAutofitConstrainedTables/&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;w:DontVertAlignInTxbx/&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/w:Compatibility&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/w:WordDocument&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/xml&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;![endif]--><!--[if gte mso 9]&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;xml&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;w:LatentStyles DefLockedState=&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;quot;false&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;quot; LatentStyleCount=&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;quot;276&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;quot;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/w:LatentStyles&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/xml&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;![endif]-->
<!--[if gte mso 10]&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;style&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;quot;Table Normal&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;quot;;
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-parent:&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;quot;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;quot;;
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin:0in;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:12.0pt;
font-family:&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;quot;Times New Roman&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;quot;;
mso-ascii-font-family:Cambria;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;quot;Times New Roman&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;quot;;
mso-fareast-theme-font:minor-fareast;
mso-hansi-font-family:Cambria;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;quot;Times New Roman&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;quot;;
mso-bidi-theme-font:minor-bidi;}
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/style&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;![endif]-->
<!--StartFragment-->
<p class="MsoNormal" /><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica"><span class="Apple-style-span" style="font-family: Arial, Helvetica, sans-serif; line-height: 18px; " /></p>
<p class="MsoNormal">Delivering quality software on-time and on-target is hard. With so many stakeholders involved, it's no wonder. Each has different perspectives, cultures, languages, priorities, and work cadences. Since changes can cause breakage, bureaucracy flourishes which limits the ability of the business to compete and meet the needs of their customers. </p><p class="MsoNormal">Of course this is something of a caricature, but it does
highlight one of the key problems in software delivery:<span style="mso-spacerun: yes"> </span>the existing organizational silos, processes,
and technologies often do more to keep the stakeholders apart than to foster
collaboration.<span style="mso-spacerun: yes"> </span><span style="mso-spacerun: yes"> </span>To put it mildly, there are tremendous
opportunities for improvement in the world of enterprise software
delivery.<span style="mso-spacerun: yes"> </span>Cycle times run way too
long; defects due to misconfigured infrastructure and middleware waste time,
money and effort; developers have a hard time diagnosing and fixing production
errors because they can’t get access to similarly configured systems;
production teams can’t depend on build quality, etc.<span style="mso-spacerun:
yes"> </span></p>
<p class="MsoNormal">Practices such as iterative and agile software development
primarily focused on the gap between the first two stakeholder groups – the
business and the development teams.<span style="mso-spacerun: yes">
</span>Frequent iterations, feedback from business stakeholders early and
often, and a focus on quality all help teams communicate and collaborate
towards a common outcome: working software that provides business value.<span style="mso-spacerun: yes"> </span>All too often, the collaboration
does not include the operations teams.<span style="mso-spacerun:
yes"> </span>Enter <i style="mso-bidi-font-style:normal">DevOps</i>.<span style="mso-spacerun: yes"> </span>DevOps is an emerging set of
principles and practices aimed at the second gap – between development and
operations.<span style="mso-spacerun: yes"> </span><span style="mso-spacerun: yes"> </span>Conceptually, DevOps extends the
practices of agile to include the deployment and management phases of the lifecycle.<span style="mso-spacerun: yes"> </span></p>
<p class="MsoNormal">As we’ve already <a href="https://www.ibm.com/developerworks/mydeveloperworks/blogs/invisiblethread/entry/6-ways-for-enterprises-to-adopt-devops?lang=en">discussed</a>, a
disciplined approach to DevOps is critical for enterprises to successfully
bridge this gap -- at least as critical as a disciplined approach to agile development is.<span style="mso-spacerun: yes"> </span>Practices such as continuous
build, test, integration, and delivery can help organizations move more quickly
– but those need to be coupled with appropriate governance, versioning, and
quality checks.<span style="mso-spacerun: yes"> </span>Malleable
cloud infrastructure lets us easily stand up new infrastructure – but that
infrastructure needs to be designed in collaboration between development and
operations to ensure that it meets everyone’s objectives.<span style="mso-spacerun: yes"> </span>In general, we need to combine
technologies and practices that encourage speed with mechanisms that increase visibility
and reduce risk.<span style="mso-spacerun: yes"> </span>That is
Enterprise DevOps.</p>
<p class="MsoNormal">With announcements such as our forthcoming <a href="http://www-01.ibm.com/software/rational/devops/">Smart Cloud Continuous Delivery</a> beta, IBM is starting to pay much more attention to the emerging DevOps
movement.<span style="mso-spacerun: yes"> </span>In this blog, members of
the IBM DevOps community will share our latest thinking on DevOps and how it
can be applied at enterprise scale.<span style="mso-spacerun: yes">
</span>The focus will not be on products.<span style="mso-spacerun:
yes"> </span>We will try to talk equally about the changes in
people, process, and technology that are necessary to help businesses
accelerate their software delivery lifecycle.<span style="mso-spacerun:
yes"> </span>We look forward to comments and feedback from
anyone interested in this topic – customers, business partners, analysts, and
even competitors.<span style="mso-spacerun: yes"> </span>We
hope this blog becomes an interesting forum for conversation about the emerging
topic of Enterprise DevOps.</p><div> </div>
<!--EndFragment-->
Delivering quality software on-time and on-target is hard. With so many stakeholders involved, it's no wonder. Each has different perspectives, cultures, languages, priorities, and work cadences. Since changes can cause breakage, bureaucracy flourishes which...104732urn:lsid:ibm.com:blogs:entries-f0c7afc6-81fd-40d8-a7ae-0775c21390bbEnterprise DevOps2014-12-04T04:27:33-05:00