Many large organizations have heavyweight change management processes that generate lead times of several days or more between asking for a change to be made and having it approved for deployment. This is a significant roadblock for teams trying to implement continuous delivery. Often frameworks like ITIL are blamed for imposing these kinds of burdensome processes. However it’s possible to follow ITIL principles and practices in a lightweight way that achieves the goals of effective service management while at the same time enabling rapid, reliable delivery. In this occasional series I’ll be examining how to create such lightweight ITIL implementations. I welcome your feedback and real-life experiences.

While continuous deployment implies continuous delivery the converse is not true. Continuous delivery is about putting the release schedule in the hands of the business, not in the hands of IT. Implementing continuous delivery means making sure your software is always production ready throughout its entire lifecycle – that any build could potentially be released to users at the touch of a button using a fully automated process in a matter of seconds or minutes. [...] In the world of continuous delivery, developers aren’t done with a feature when they hand some code over to testers, or when the feature is “QA passed”. They are done when it is working in production. That means no more testing or deployment phases, even within a sprint (if you’re using Scrum)...

Docker encapsulates heterogeneous payloads in Standard Containers, and runs them on any server with strong guarantees of isolation and repeatability. It is a great building block for automating distributed systems: large-scale web deployments, database clusters, continuous deployment systems, private PaaS, service-oriented architectures, etc.

The first obstacle we reached when we were setting up our continuous delivery pipeline was figuring out which branch to continuously deliver. We changed our minds a few times before settling on a pipeline that would run all the code from the development branch. Except production, that is, which would deploy from master. This was always a bit confusing and didn't make a whole lot of sense. The idea with git flow is that master always represents production while develop represents the current state of development. The idea of continuous delivery, though, is to reduce the time between what master represents and what develop represents. In the ideal case, develop and master would converge. These worldviews clash quite spectacularly when tried to use in conjunction.

The iteration is a cornerstone of agile development. It provides a heartbeat for the team and its stakeholders, and a structure for various routine activities that help keep development work aligned with what the customer needs. However, the way many teams run their iterations creates serious pitfalls which can keep them from delivering software as effectively as they could.

The orthodox approach to the iteration is to treat it as a timebox for delivering a batch of stories, which is the approach most Scrum teams take with sprints (the Scrum term for an iteration). In recent years many teams have scrapped this approach, either using iterations more as a checkpoint, as many ThoughtWorks teams do, or scrapping them entirely with Kanban and Lean software development.

Togglz is an implementation of the Feature Toggles pattern for Java. Feature Toggles are a very common agile development practices in the context of continuous deployment and delivery. The basic idea is to associate a toggle with each new feature you are working on. This allows you to enable or disable these features at application runtime, even for individual users.

|< First   < Previous   21–26 (26)