DevOps Stack Exchange is a question and answer site for software engineers working on automated testing, continuous delivery, service integration and monitoring, and building SDLC infrastructure. It only takes a minute to sign up.
Sign up to join this community
I'm not clear how a Sprint which is timed-box to a predetermined length (1/2/3 weeks) fits with a DevOps principle of being able to deploy on demand or as needed.
Is deploying to production part of the definition of done rather than a post activity to the overall sprint?
How does the sprint process capture that code was deployed to production in the middle of a sprint rather than at the end where the goal is to have "potentially shippable product"?
There is no "Deploy-once-a-day" rule in devops philosophy. It's more of: Deploy as soon as possible and as often as possible. Also it calls for decoupling architecture so different parts of it may be released separately and also for decoupling deploys from release.
The Deveops Handbook by Gene Kim et al.calls for modifying Definition of Done to include running in production-like environments. That is follow the devops principles all the time during the sprint.
What you want to avoid is ending a sprint with all the developers handing over their code that is tested, is working but is not integrated and is handed to other team to be deployed, somehow.
I'd argue that definition of done is : it's not done until it's ready to run in production. Once it's ready you may or may not release it depending on your specific business needs and the sprint goal but if it's not ready to be released right now it's not done.
In a sense your question exactly underlines the problem faced by teams trying to be agile but without having the benefits of a good DevOps culture in place: there is practically no guarantee that at the end of each sprint they'll be able to deliver to their customers.
In some cases teams may end up using more relaxed definitions of done (like passed QA in my workspace/branch) or may account the additional steps for making the code shippable as tasks.
But with DevOps being able to deploy on demand or as needed shipping at the end of the sprint should simply be normal. Agile and DevOps really work very well together.
Side note: personally I find the able to deploy on demand or as needed a stretch - that only happens if the CI/CD processing passes all necessary QA checks. Very few CI/CD tools out there are able to actually guarantee it.
The Agile software development method
describes a set of values and principles for software development under which requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams. It advocates adaptive planning, evolutionary development, early delivery, and continuous improvement, and it encourages rapid and flexible response to change.
The term agile (sometimes written Agile) was popularized by the Agile Manifesto, which defines those values and principles. Agile software development frameworks continue to evolve, two of the most widely used being Scrum and Kanban.
While there is no rule prohibiting using DevOps at the end of a Scrum Sprint to deploy the Sprint's results (in fact, it's encouraged - you are less likely to have mistakes and more likely to have production deployed identical to dev and test) DevOps is really better suited to Kanban than Scrum.
This is because the DevOps philosophy of rapid testing and release targeting 10+ deploys a day is better suited to releasing every time a work item is completed, which more closely aligns with the rapid feedback and response model outlined in the Second Way of DevOps.
However, even during a sprint, DevOps may be helpful to deploy code to testing, QA and staging and have pre-canned automated testing run through the testing units and report results or set up a new sandbox environment. This can allow developers still get the rapid, amplified feedback that DevOps can provide and increase the time spent coding instead of wasting that time prepping development environments - even if you do not deploy all the way to production.
Some great answers here, but I thought I'd chime in with an example of how we deliver features. "shipping" to production is not the goal, the goal is to deliver value. Shipping code to production is a means to an ends and we usually deploy many times to enable a feature. Here's a contrived example using a 1 week sprint for succinctness.
During planning on Monday the team discusses the new feature they want to implement and decide some refactoring work needs to be done before it can be implemented. Not doing the refactoring would introduce extra technical debt and potential performance issues. They spend the rest of Monday and most of Tuesday refactoring and ship this change Tuesday afternoon. This change is not visible to users.
Wednesday and Thursday they spend implementing the feature and deploy it to production at lunchtime Thursday, but only to a subset of users (using feature flags or a/b testing). Friday morning they find a bug in their code or maybe an undesirable outcome from the testing and ship an update at lunch time. Later they enable the feature for everybody.
This contrived example involved three deployments before the feature was considered "done". Most importantly it makes use of fast feedback to drive feature delivery. Taking the approach of writing features and deploying them as the "end game" introduces longer feedback cycles and makes your team slow to react i.e. less Agile.
I'm not clear how a Sprint which is timed-box to a predetermined length (1/2/3 weeks) fits with a DevOps principle of being able to deploy on demand or as needed.
As usual, there is no commonly agreed-upon definition of DevOps, or description of what it entails, so we're just spouting opinions here. But in mine, DevOps encourages operations engineers to do as much as they can to get out of the way of developers, which includes not being a blocker for deploys unless they actually need to be (provisioning, architecture review, etc.).
That's not really tied to the development cycle at all - no matter what the cycle is, your job is to not be a blocker in it.
How does the sprint process capture that code was deployed to production in the middle of a sprint rather than at the end where the goal is to have "potentially shippable product"?
It depends of course on your company, but in my opinion a feature isn't done until users have it.
