Tag Archives: Continuous Delivery

Dzone Guide to Continuous Delivery from @AgileSteveSmith & @Matthewpskelton

Our good friends and organisers of PipelineConf @AgileSteveSmith and @Matthewpskelton have contributed to the DZone Guide to Continuous Delivery.

The guide covers:

  1. SUMMARY & HIGHLIGHTS
  2. KEY RESEARCH FINDINGS
  3. INTRODUCING: CONTINUOUS DELIVERY BY STEVE SMITH
  4. CONTINUOUS DELIVERY PITFALLS BY J. PAUL REED
  5. THE CONTINUOUS DELIVERY TOOLCHAIN BY MATTHEW SKELTON
  6. CONTINUOUS DELIVERY VISUALIZED
  7. INFRASTRUCTURE AS CODE: WHEN AUTOMATION ISN’T ENOUGH BY MITCH PRONSCHINSKE
  8. CONTINUOUS DELIVERY MATURITY CHECKLIST

Dzone 2014 CD guideWell worth a read!

 

Why companies are investing in DevOps and Continuous Delivery

A thought-provoking infographic – with some interesting data points – shows how companies are reaping real rewards from investing in agile software delivery processes. Check out the graphic – from Zend – for more on how DevOps and Continuous Delivery are bridging the speed and innovation gap between business demand and IT.

Continuous Delivery Infographic by Zend Technologies.

Continuous Delivery Infographic

BamiWvqCIAAfBgw

Upgrading to Octopus 2.0

On 20th December 2013, Paul Stovell and the Octopus Team released Octopus Deploy 2.0. We’ve had a chance to play with the product for sometime, and it’s a great next version.

Here’s 5 great reasons to upgrade;

  1. Configurable Dashboards
  2. Sensitive variables
  3. Polling Tentacles (Pull or Push)
  4. IIS website and application pool configuration
  5. Rolling deployments

So let’s take a look at how the upgrade process works.

Step 1 – Backup your existing database

Things to check before you upgrade;

  1. Your administrator username and password (especially, if you are not using Active Directory)
  2. Before attempting to migrate, make sure that you don’t have any projects, environments, or machines with duplicated names (this is no longer allowed in Octopus 2.0, and the migration wizard will report an error if it finds duplicates).
  3. IIS Configuration. Are you using ARR or rewrite rules of any kind.
  4. SMTP Server Settings (these are not kept in upgrade)

The first step is to ensure that you have a  recent database backup that you can restore in case anything goes wrong.

1 - Database Backup

Confirm the location of your backup file. You’ll need this file at a later stage in the upgrade process (and if anything goes wrong)

2-Database Backup Location

Step 2 – Install Octopus 2.0

Download the latest installer MSI from the Octopus Website at http://octopusdeploy.com/downloads

Next follow the installer instructions and the Octopus Manager process. This process is really straight forward, and if you’ve installed Octopus before you’ll be familiar with most of the process. There’s a great video here on how to install Octopus http://docs.octopusdeploy.com/display/OD/Installing+Octopus

Step 3 – Import Previous Octopus Database

Once you’ve installed Octopus 2.0, you’ll most likely want to import your old v1.6 database with all your existing configuration. To do this, select the “import from Octopus 1.6″ option and choose the database back-up from the process you followed in step 1 and follow the instructions.

3 - Import Octopus Database

Step 4 – Post Upgrade Steps (server)

When you have completed the installation it’s essential to task a copy of the master key for backups. Instructions on how to backup the key can be found here http://docs.octopusdeploy.com/display/OD/Security+and+encryption

Once you have the server installed there’s a couple of items you’ll need to configure again.

  1. SMTP Server Settings are not kept, so these will need to be re-entered.

Step 5 – Upgrading Tentacles

If you are upgrading from version 1.6 – Octopus 2.0 server can no longer communicate with Tentacle 1.6. So in addition to upgrading Octopus, you’ll also need to upgrade any Tentacles manually. There are two ways to achieve this;

1. Download and Install the new Octopus Deploy Tentacle MSI on each target server

2. Use  a PowerShell script to download the latest Tentacle MSI, install it, import the X.509 certificate used for Tentacle 1.6, and configure it in listening mode. The powershell script is as follows;

function Upgrade-Tentacle
{ 
  Write-Output "Beginning Tentacle installation"
  Write-Output "Downloading Octopus Tentacle MSI..."
  $downloader = new-object System.Net.WebClient
  $downloader.DownloadFile("http://download.octopusdeploy.com/octopus/Octopus.Tentacle.2.0.5.933.msi", "Tentacle.msi")
  
  Write-Output "Installing MSI"
  $msiExitCode = (Start-Process -FilePath "msiexec.exe" -ArgumentList "/i Tentacle.msi /quiet" -Wait -Passthru).ExitCode
  Write-Output "Tentacle MSI installer returned exit code $msiExitCode"
  if ($msiExitCode -ne 0) {
    throw "Installation aborted"
  }
  
  Write-Output "Configuring and registering Tentacle"
   
  cd "${env:ProgramFiles(x86)}\Octopus Tentacle 2.0\Agent"
  Write-Output "Stopping the 1.0 Tentacle"
  
  & .\tentacle.exe create-instance --instance "Tentacle" --config "${env:SystemDrive}\Octopus\Tentacle\Tentacle.config" --console
  & .\tentacle.exe configure --instance "Tentacle" --home "${env:SystemDrive}\Octopus" --console
  & .\tentacle.exe configure --instance "Tentacle" --app "${env:SystemDrive}\Octopus\Applications" --console
  & .\tentacle.exe configure --instance "Tentacle" --port "10933" --console
  & .\tentacle.exe import-certificate --instance "Tentacle" --from-registry  --console
  Write-Output "Stopping the 1.0 Tentacle"
  Stop-Service "Tentacle"
  Write-Output "Starting the 2.0 Tentacle"
  & .\tentacle.exe service --instance "Tentacle" --install --start --console
  
  Write-Output "Tentacle commands complete"
}
  
Upgrade-Tentacle

Step 6 – Upgrade TeamCity Integration

The JetBrains TeamCity Plugin has also been released and requires an upgrade. To do this

  1. Download the plugin from the Octopus Website http://octopusdeploy.com/downloads.
  2. Shutdown the TeamCity server.
  3. Copy the zip archive (Octopus.TeamCity.zip) with the plugin into the <TeamCity Data Directory>/plugins directory.
  4. Start the TeamCity server: the plugin files will be unpacked and processed automatically. The plugin will be available in the Plugins List in the Administration area.

Please Note: The API Key’s for the users will have changed and will need to be re-entered into the Octopus Deploy Runner Configuration within the Build Step

Summary

We think that overall the Octopus Team have done a great job making the upgrade process easy. There’s still a few little issues to iron out, but overall the process is robust and simple. It’s a shame that automatic upgrade of the tentacles couldn’t have been supported as this may cause pain for customers with a large server install base, but Powershell automation makes for a great workaround.

As we learn more about Octopus 2.0, we’ll continue to let you know what we find. Good Luck with Upgrading — it’s definitely worth it!

DevOpsGuys use Octopus Deploy to deliver automated deployment solutions – ensuring frequent, low-risk software releases into multiple environments. Our engineers have deployed thousands of software releases using Octopus Deploy and we can help you do the same. Contact us today – we’d be more than happy to help.

requirements_rotated

The Top Ten DevOps “Operational Requirements”

Join us for “The Top 10 DevOps Operational Requirements” –  http://www.brighttalk.com/webcast/534/98059 via @BrightTALK

One of the key tenets in DevOps is to involve the Operations teams in the full software development life cycle (SDLC) and in particular to ensure that “operational requirements” (“OR’s”, formerly known as “non-functional requirements”, “NFR’s”) are incorporated into the design&build phases.

In order to make your life easier the DevOpsGuys have scoured the internet to compile this list of the Top Ten DevOps Operational Requirements (ok, it was really just chatting with some of the guys down the pub BUT we’ve been doing this a long time and we’re pretty sure that if you deliver on these your Ops people will be very happy indeed!).

#10 – Instrumentation

Would you drive a car with a blacked out windscreen and no speedo? No, didn’t think so, but often Operations are expected to run applications in Production in pretty much the same fashion.

Instrumenting your application with metrics and performance counters gives the Operations people a way to know what’s happening before the application drives off a cliff.

Some basic counters include things like “transactions per second” (useful for capacity) and “transaction time” (useful for performance).

#9 – Keep track of the Dependencies!

“Oh yeah, I forgot to mention that it needs [dependency XYZ] installed first” or “Yes, the system relies on [some 3rd party web service] can you just open up firewall port 666 right away”.

Look, we all understand that modern web apps rely on lots of 3rd party controls and web services – why re-invent the wheel if someone’s already done it, right? But please keep track of the dependencies and make sure that they are clearly documented (and ideally checked into source control along with your code where possible). Nothing derails live deployments like some dependency that wasn’t documented and that has to be installed/configured/whatever at the last moment. It’s a recipe for disaster.

#8 – Code defensively & degrade gracefully

Related to #9 above – don’t always assume the dependencies are present, particularly when dealing with network resources like databases or web services and even more so in Cloud environments where entire servers are known to vanish in the blink of an Amazon’s eye.

Make sure the system copes with missing dependences, logs the error and degrades gracefully should the situation arise!

#7 – Backward/Forward Compatibility

Existing code base with new database schema or stored procedure?

New code base with existing database schema or stored procedures?

Either way, forwards or backwards, it should work just fine because if it doesn’t you introduce “chicken and the egg” dependencies. What this mean for Operations is that we have to take one part of the system offline in order to upgrade the other part… and that can mean an impact on our customers and probably reams of paperwork to get it all approved.

#6 – Configurability

I once worked on a system where the database connection string was stored in a compiled resource DLL.

Every time we wanted to make a change to that connection string we had to get a developer to compile that DLL and then we had to deploy it… as opposed to simply just editing a text configuration file and re-starting the service. It was, quite frankly, a PITA.

Where possible avoid hard-coding values into the code;  they should be in external configuration files that you load (and cache) at system initialisation. This is particularly important as we move the application between environments (Dev, Test, Staging etc) and need to configure the application for each environment.

That said, I’ve seen systems that had literally thousands of configuration options and settings, most of which weren’t documented and certainly were rarely, if ever, changed. An “overly configurable” system can also create a support nightmare as tracking down which one of those settings has been misconfigured can be extremely painful!

#5 – “Feature Flags”

A special case of configurability that deserves its own rule – “feature flags”.

We freakin’ love feature flags.

Why?

Because they give us a lot of control over how the application works that we can use to (1) easily back out something that isn’t working without having to roll-back the entire code base and (2) we can use it to help control performance and scalability.

#4 – Horizontal Scalability (for all tiers).

We all want the Product to be a success with customers BUT we don’t want to waste money by over-provisioning the infrastructure upfront (we also want to be able to scale up/down if we have a spiky traffic profile).

For that we need the application to support “horizontal scalability” and for that we need you to think about this when designing the application.

3 quick “For Examples”:

  1. Don’t tie user/session state to a particular web/application server (use a shared session state mechanism).
  2. Support for read-only replicas of the database (e.g. a separate connection string for “read” versus “write”)
  3. Support for multi-master or peer-to-peer replication (to avoid a bottleneck on a single “master” server if the application is likely to scale beyond a reasonable server specification). Think very carefully about how the data could be partitioned across servers, use of IDENTITY/@Auto_Increment columns etc.

#3 –Automation and “scriptability”

One of the key tenets in the CALMS DevOps Model is A for Automation (Culture-Automation-Lean-Metrics-Sharing if you want to know the others).

We want to automate the release process as much as possible, for example by packaging the application into versionable released or the “infrastructure-as-code” approach using tools like Puppet & Chef for the underlying “hardware”.

But this means that things need to be scriptable!

I can remember being reduced to using keystroke macros to automate the (GUI) installer of a 3rd party dependency that didn’t have any support for silent/unattended installation. It was a painful experience and a fragile solution.

When designing the solution (and choosing your dependencies) constantly ask yourself the question “Can these easily be automated for installation and configuration”? Bonus points if you can, in very large scale environments (1,000 of servers) build in “auto-discovery” mechanisms where servers automatically get assigned roles, service auto-discovery (e.g. http://curator.apache.org/curator-x-discovery/index.htm) etc.

#2 – Robust Regression Test suite

Another think we love, almost as much as “feature flags” is a decent set of regression test scripts that we can run “on-demand” to help check/verify/validate everything is running correctly in Production.

We understand that maintaining automated test scripts can be onerous and painful BUT automated testing is vital to an automation strategy – we need to be able to verify that an application has been deployed correctly, either as part of a software release or “scaling out” onto new servers, in a way that doesn’t involve laborious manual testing. Manual testing doesn’t scale!

The ideal test suite will exercise all the key parts of the application and provide helpful diagnostic messaging if something isn’t working correctly. We can combine this with the instrumentation (remember #10 above), synthetic monitoring, Application Performance Management (APM) tools (e.g. AppDynamics), infrastructure monitoring (e.g. SolarWinds) etc to create a comprehensive alerting and monitoring suite for the whole system. The goal is to ensure that we know something is wrong before the customer!

#1 – Documentation

Contrary to popular belief we (Operations people) are quite happy to RTFM.

All we ask is that you WTFM (that’s W as in WRITE!) J

Ideally we’d collaborate on the product-centric documentation using a Wiki platform like Atlassian Confluence as we think that this gives everyone the easiest and best way to create – and maintain – documentation that’s relevant to everyone.

As a minimum we want to see:

  1. A high-level overview of the system (the “big picture”) probably in a diagram
  2. Details on every dependency
  3. Details on every error message
  4. Details on every configuration option/switch/flag/key etc
  5. Instrumentation hooks, expected values
  6. Assumptions, default values, etc

Hopefully this “Top Ten” list will give you a place to start when thinking about your DevOps “Operational Requirements” but it’s by no means comprehensive or exhaustive. We’d love to get your thoughts on what you think are the key OR’s for your applications!

Our experienced DevOps team provides a fully-managed “application-centric” website support service to your business and  your customers. Contact us to today, to find out how we can help.

image source: - CC  - c_knaus via Flickr - http://www.flickr.com/photos/soda37/6496536471

Continuous Integration & Delivery – Christmas Reading Essentials

Continuous Integration: Improving Software Quality and Reducing Risk
Continuous Integration: Improving Software Quality and Reducing Risk
by Paul M. DuvallSteve MatyasAndrew Glover
Learn more

Add to Wish List

Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler))
Continuous Delivery: Reliable Software Releases through Build…
by Jez HumbleDavid Farley
Learn more

Add to Wish List

Agile Testing: A Practical Guide for Testers and Agile Teams
Agile Testing: A Practical Guide for Testers and Agile Teams
by Lisa CrispinJanet Gregory
Learn more

Add to Wish List

Continuous Delivery and DevOps: A Quickstart guide
Continuous Delivery and DevOps: A Quickstart guide
by Paul Swartout
Learn more

Add to Wish List

Test Driven Development: By Example
Test Driven Development: By Example
by Kent Beck
Learn more

Add to Wish List

Jenkins Continuous Integration Cookbook
Jenkins Continuous Integration Cookbook
by Alan Berg
Learn more

Add to Wish List

How Google Tests Software
How Google Tests Software
by James A. WhittakerJason ArbonJeff Carollo
Learn more

Add to Wish List

Jenkins: The Definitive Guide
Jenkins: The Definitive Guide
by John Ferguson Smart
Learn more

Add to Wish List

Growing Object-Oriented Software, Guided by Tests
Growing Object-Oriented Software, Guided by Tests
by Steve FreemanNat Pryce
Learn more

Add to Wish List

Succeeding with Agile: Software Development Using Scrum
Succeeding with Agile: Software Development Using Scrum
by Mike Cohn
Learn more

Add to Wish List

User Stories Applied: For Agile Software Development
User Stories Applied: For Agile Software Development
by Mike Cohn
Learn more

Add to Wish List

Refactoring to Patterns
Refactoring to Patterns
by Joshua Kerievsky
Learn more

Add to Wish List

Essential Scrum: A Practical Guide to the Most Popular Agile Process (Addison-Wesley Signature Series (Cohn))
Essential Scrum: A Practical Guide to the Most Popular Agile…
by Kenneth S. Rubin
Learn more

Add to Wish List

Service Design Patterns: Fundamental Design Solutions for SOAP/WSDL and RESTful Web Services
Service Design Patterns: Fundamental Design Solutions for SOAP/WSDL…
by Robert Daigneau
Learn more

Add to Wish List

Web Operations: Keeping the Data On Time
Web Operations: Keeping the Data On Time
by John AllspawJesse Robbins

Continuous Delivery Adoption Barriers

For about a month, DevOpsGuys has been running a survey to understand what barriers exist for Continuous Delivery adoption. We’ve analysed the results and published our findings below. We’ve love to hear your feedback, so let us know what you think through the comments section.

barriers to cd

1. Organisation Culture (41%)

Organisational culture is probably the most important aspect to consider when adopting sustainable Continuous Delivery principles. 41% of respondents said that organisational culture was seen as the primary barrier to Continuous Delivery adoption.

Organizational culture is capable of blunting or significantly altering the intended impact of even well-thought-out changes in an organization.

Organisations seeking to adopt Continuous Delivery will primarily focus on evaluating and improving working practice, but to truly embrace Continuous Delivery, organisations must ensure that their employees encompass its primary principles. Continuous Delivery adoption is usually impossible unless management is bought in and at least some of the engineers are willing to change the way they work.

As organizations mature their Continuous Delivery adoption they must seek to embrace a culture which;

  • Is open, honest and transparent.
  • Encourages collaboration.
  • Promotes innovation, accountability and responsibility.
  • Builds and Rewards trust across organizational boundaries.
  • Enhances visibility of change and risk.

Organizational change is hard; it’s well known, theorised and documented and culture is the most difficult organisational attribute to change. For Continuous Delivery to be truly successful, the entire organisation must adopt its philosophy; to provide high-quality, valuable software as quickly as possible.

2. Lack of integrated development and operations (DevOps) (19%)

DevOps does provide an implementation strategy for Continuous Delivery principles, but neither philosophy is truly dependent on the other.  Continuous Delivery and DevOps are working towards common goals by providing business value through software delivery, within a culture that enables collaboration and understanding between the functional groups that deliver IT services where everyone is responsible for delivery.

Within the DevOps movement, Silo’s between teams are being removed so that software can be delivered quicker. That is, business value can be delivered quicker.

Developers are learning how to create production-ready software that can always be deployed, thus delivering high throughput and Operations are learning that Agile principles can enable effective and low risk change management, thus protecting stability.

recent study by Forrester Consulting and ThoughtWorks found that;

  • Companies are looking to prioritize innovation through developing software services.
  • Software development providers can’t deliver new services at the rate business leaders want.
  • Corporate culture and development process immaturity impede communication and slow service delivery.
  • Few IT organizations regularly perform advanced continuous delivery practices.

Therefore, it is not surprising that 19% of respondents consider a lack integrated development and operations capability as an adoption barrier for Continuous Delivery.

3. Technical hurdles (15%)

While Organizational Culture might be the primary adoption barrier for Continuous Delivery, there are also a number of technical hurdles to overcome. The technical challenges fall into 4 broad categories.

  • Configuration Management
  • Continuous Integration
  • Automated Testing
  • Automated Deployment

In each of these areas tools and associated best practice are becoming more advanced. Infrastructure-as-Code as promoted by OpsCode and Delivery Pipeline Management tools such as ThoughtWorks Go are being combined with an ever growing set of Cloud enabled services and platforms to make Continuous Delivery adoption easier from a technical viewpoint. However 15% of respondents believe that technical hurdles are significant in preventing adoption of Continuous Delivery.

4. Lack of understanding (15%)

Education of Continuous Delivery principles was seen as a big adoption barrier by 15% of respondents. Lack of understanding spans each of the possible responses in our survey from organisational culture through technical knowledge.

But there are more basic misunderstandings of the terminology, principles and practice of Continuous Delivery. As Paul Stack points out Continuous Delivery is not continuous deployment. Paul correctly defines Continuous Delivery as the process of having shippable software after each check in to source control, whereas Continuous Deployment is the process of shipping your product after every check in to source control. The difference is subtle but significant.

Another misconception is that Continuous Delivery and DevOps are basically the same thing. As Stephen Smith observes, Continuous Delivery and DevOps are interdependent, not equivalent. Some of this confusion may have arisen from the  misinterpretation of the DevOps principles leading to differing opinions of the relationship  between Continuous Delivery and DevOps, especially as “People often talk about DevOps and Continuous Delivery in the same breath.” as Jeff Sussna notes.

5. Business readiness to accept change at a fast pace (10%)

In many organizations, change can often feel constant. However as Isaac Asimov said “The only constant is change”. In general, people don’t like change, so methodology that promotes the acceleration of change is likely to face opposition. Only 10% of respondents saw business readiness to accept change at a quicker pace as a barrier to Continuous Delivery adoption. However, this may be influenced by the mainly technical community completing the survey.

Reducing the Mean-time-to-deploy can have significant business advantages. Continuous Delivery aims to provide high-quality and valuable software as quickly as possible. That is, to deliver business value is less time, whilst protecting the value quality. Given, respondents saw this reason as the least important factor is preventing Continuous Delivery adoption – could mean that organizations are aware of the benefits of getting to market faster.

For organizations aware of the benefits of delivering value at a quicker pace, and for those willing to embrace cultural change, Continuous Delivery provides a set of principles, which if implemented can provide significant benefit.

slide2

This week in DevOps #1

TWIDO

We hate acronyms, but this one’s kinda catchy. This Week in DevOps (TWIDO) [[[ yeah, yeah, we promise not to use it again]]], is going to be a Friday round up of stuff we found interesting this week.

We’d love you to contribute, if you have articles, research, tweets on any other stuff you’d like to share, please get involved.

#1:  Q&A From Building a DevOps Team That Isn’t Evil

Q: How have auditors been ok with a devops model where devs have access to prod? e.g., continuous testing, automation, version control, logging, etc?  is one single dev allowed to push a code chg thru the entire process?

Few public companies allow a developer to go from change to production, or access production databases directly. There may still be roles with responsibility for building new features and others that operate on production. The goal is enhance the flow of knowledge between the people in those roles, and for there to be some joint responsibility. For instance, logs may be exposed to developers without giving access to the production box. I think the team at Stackify is trying to make a business around exactly that.

http://architects.dzone.com/articles/qa-building-devops-team-isnt 

Commentary

DevOps does not equal developers managing production. It’s aimed at promoting understand and collaboration between groups.  Thanks to Eric Minick from DevOps Zone and UrbanCode for supporting this.

#2: IT stability and business innovation are not enemies.

Q: DevOps promises a more responsive, more collaborative IT department that can realize business ideas faster. So what is holding back its widespread adoption? What’s the challenge or downside?

DE: There was a movie called “Charlie Wilson’s War” that had a great line between Tom Hanks, playing a U.S. Congressman, and Philip Seymour Hoffman, playing a CIA agent. Hoffman asks, “Why is Congress saying one thing and doing nothing?” Hanks replies, “Well, tradition mostly.”

All jokes aside, tradition is a powerful thing and hard to break. Tradition, or “what we’ve always done,” in IT is no different. There was a thread on Slashdot just this past month that asked whether developers should be allowed to deploy their own applications. You should have seen the outcry. The sheer number of commenters who shot down the idea as pure heresy was shocking. And the richest part of all of their denunciation was that the mob said over and over that the idea would “never work at a real company with real revenue at stake.” I thoroughly enjoyed sending that to John Allspaw, who runs all of technology at Etsy, and Jesse Robbins, who was in charge of risk and disaster planning for operations at Amazon. Etsy does over $600 million of transactions per year, and Amazon does about $50 billion in revenue. In both companies, developers are the ones who deploy and own the uptime for their own code. John’s reaction to the thread was a simple yet priceless one: “OMG.”

http://dev2ops.org/2013/02/

Commentary

Empowering development, operations and even QA teams to take ownership of code deployment is crucial for DevOps teams. It ensures that developers work with operations to understand the impact of change and take accountability/ownership for the “uptime of thier own code”. It also ensures that operations understand what changes are coming and how best to support the change. Uptime is a shared responsibility  with the environment the code executes within and the code that is executing both factors that must be managed correctly. 

#3 – StartOps: Growing an ops team from 1 founder

Bootstrapped startups don’t have the luxury of a full team of ops engineers available to respond to issues 24/7, so how can you survive on your own? This talk will tell the story of how to run your infrastructure as a single founder through to growing that into a team of on call engineers. It will include some interesting war stories as well as tips and suggestions for how to run ops at a startup.

http://devopsdays.org/events/2013-london/

Commentary

We are really looking forward to this track at DevOps Days London. DevOpsGuys are attending. Would be great to meet some of you.

#4: Engineering running the production environment

http://devopsreactions.tumblr.com/post/43882100705/engineering-running-the-production-environment

Commentary

Both funny and awesome! Nuff said!

#5:  Top 10 Practices for Effective DevOps

Practice 1: Active Stakeholder Participation

A fundamental philosophy of DevOps is that developers, operations staff, and support people must work closely together on a regular basis. An implication is that they must see one other as important stakeholders and actively seek to work together. A common practice within the agile community is “onsite customer,” adopted from Extreme Programming (XP), which motivates agile developers to work closely with the business. Disciplined agilists take this one step further with the practice of active stakeholder participation, which says that developers should work closely with all of their stakeholders, including operations and support staff–not just business stakeholders. This is a two-way street: Operations and support staff must also be willing to work closely with developers.

Practice 6: Integrated Deployment Planning

From the point of view of development teams, deployment planning has always required interaction with an organization’s operations staff; in some cases, via liaison specialists within operations typically called release engineers. Experienced development teams will do such planning continuously throughout construction with active stakeholder participation from development, operations, and support groups. When you adopt a DevOps strategy, you quickly realize the need to take a cross-team approach to deployment planning due to the need for operations staff to work with all of your development teams. This isn’t news to operations staff, but it can be a surprise to development teams accustomed to working in their own siloed environments. If your team is not doing this already, you will need to start vying for release slots in the overall organizational deployment schedule. Furthermore, to support continuous deployment, release engineers will need to increase the number of release slots available to agile teams that are disciplined enough to continuously and consistently meet the quality requirements for release.

Practice 7: Continuous Deployment

Continuous deployment extends the practice of continuous integration. With continuous deployment, when your integration is successful in one sandbox, your changes are automatically promoted to the next sandbox, and integration is automatically started there. This automatic promotion continues until the point where any changes must be verified by a person, typically at the transition point between development and operations.

Continuous deployment enables development teams to reduce the time between a new feature being identified and being deployed into production. It enables the business to be more responsive. However, continuous deployment increases operational risk by increasing the potential for defects to be introduced into production when development teams aren’t sufficiently disciplined. Successful continuous deployment in an enterprise environment requires all the practices described earlier.

Commentary

Overall we found this article rather in conflict with itself. It’s interesting how the author views Operations and Development as separate stakeholders within a process. The principles of DevOps are to break this view and to combine Development and Operations as a single entity and in this context they should be considered a single StakeHolder.

We fully agree that Operations should be managers of production with development participation, as Developers should be mangers of development with Operations participation, but on deployment we differ with the author. It’s easy in our view. If operations are a bottleneck to deployment, expand the role of “release engineers” to encapsulate the entire team. Anyone should be able to take accountability for and action deployment if the correct principles and practices have been applied.

The author also battles with Continuous Delivery principles. “release engineers will need to increase the number of release slots available to agile teams”. If you adopt a continuous delivery process your actually going to reduce the number of release slots, to one. One continuous release slot. Hence Continuous Delivery.

http://www.drdobbs.com/architecture-and-design/top-10-practices-for-effective-devops/240149363

#5: Tweet of the Week

Every #ITmanager, no matter how strong he is, lies to himself about his #DevOps initiative. I will find your lie. I will break you