DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. An Agile Introduction to DevOps, Part IV: Ship Ahoy!

An Agile Introduction to DevOps, Part IV: Ship Ahoy!

You've finally tested your software! How exciting! However, that means nothing if you don't get it out to actual customers.

Gil Zilberfeld user avatar by
Gil Zilberfeld
·
Nov. 16, 16 · Opinion
Like (1)
Save
Tweet
Share
2.99K Views

Join the DZone community and get the full member experience.

Join For Free

this is the fourth part of a series on agile and devops.  part i  ,  part   ii  , and  part iii  should be read first!

strange yippee! we now have tested software...

...which means nothing if we don’t get it to actual customers. so, let’s talk about shipping to production. like everything we discussed until now, automation lowers the risk of manual errors and saves time.

even deploying to production has to have some kind of method to it. we’ve already discussed  version management  , but that was more internal, and therefore in our control. going out to the wild means we’re going to lose control, so we want to minimize the risk.

shipping along side-by-side

it used to be that “side-by-side” meant two versions running at the same time. things have become more complex since.

first of all, we need to define a version in deployment. it’s easier if we think in an “all or nothing,” binary way; as in, whatever i release, the version number was just incremented.

however, is that always true? what if i open a feature just for new zealand? which version am i running right now?

like with doctor strange, we’re now adding multiple dimensions to our situation. since we can deploy to multiple servers, what happens between starting the deployment on server 1 until it’s fully replicated and deployed to server  n  ?

the real issue is not identification but reproduction. if something happened during the process of deployment and we want to reproduce it, we need to know the conditions. it used to be that version numbers were all we needed. that is not so anymore, and devops methods need to answer both identification and reproduction numbers.

versions used to be helpful when something went wrong. if that happened, we would simply roll back to a previous version. well, if we don’t have a definition of what a version means, how can we roll back to one?

in fact, imagine 500 of your colleagues committing code all day, every day. now, it seems that yesterday’s deployment needed a revert. however, that means reverting everything else the guys have written. do you start separating wheat from chaff?

you don’t. organizations that understand this stopped rolling backward, and just push the fixes forward. that’s a devops understanding of how the systems work and how to manage them.

in order to do that, we need the ability to automate this kind of volume to production in a safe manner. enter continuous delivery, another method from the devops school. cd is ci’s big brother. it’s an extension of the early cycles of automation (build, developer tests, system tests) and builds on the capabilities of deployment and environment management.

continuous delivery is not just about automation. it’s about minimizing the risk of something bad going to production, and raising early warning flags before it does.

we may be “done,” but we're not “done-done.” software these days doesn’t just end when it’s in production. the devops methods reach beyond that. next time, we’ll talk about the afterlife of software.

DevOps agile

Published at DZone with permission of Gil Zilberfeld, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • 5 Challenges in Building Distributed Systems
  • Application Assessment Questions for Migration Projects
  • Essential Mobile App Security Tips for Coders in 2023: Make Your App Unhackable
  • Debugging Streams and Collections

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: