One of the goals of my new team at LinkedIn is building a brand new platform for front end engineers so that they can deploy new features to production 3 times a day. However, we don't want to just "enable" other teams to deploy to prod daily. We want to automatically deploy. Always.
This is what I find critical in continuous delivery mind shift. Enabling (through automation) to go to production frequently is not enough. A team might be enabled to deploy to prod easily and automatically. However, only when the deployment is regular and automatic (for example: triggered on every push master - like in Mockito) then the change of team's habits, thinking and behavior truly begins. Team that is enabled to continuously deliver differs so much from the team that continuously delivers. At least, this those are my subjective observations :)
I chatted about it with Peter Niederweiser, the legendary creator of spock test framework. Spock is not continuously deployed at time of writing this post (this will change, right Peter!!!?? :). Publication of new Spock versions is more interesting than Mockito because the former needs to deal with groovy variants (compile, build and run against different groovy runtime, publish artifact variants, etc.). Given the complexity of the build process there is a temptation to automate everything to the point when all artifacts, documentation, release notes can be published via a one click. I'd say it's not enough. Enabling for continuous delivery is simply not as gratifying as doing it all the way through.
It's hard to explain what changes when the team does true continuous delivery. The attitude to a code commit is different. Commit messages get better. Tests are cleaner and deeper, more thoughtful. There is more vigor in battling flaky tests (fact of life: continous delivery == lots of tests == flaky tests). There is more energy to improve the automation even further. To make the automated release notes look better. So on, so on.
I'm on a mission to do continuous and automatic delivery and not merely enable it. I hope I managed to stir you up a bit, too :) Right now I'm lonely at Munich airport waiting for a connecting flight to Krakow. In a week, I'm moving my family over to Santa Clara CA. I got pretty agitated writing this post, hopefully the content makes sense. Keep in mind that it's my subjective experience.
Sunday, February 1, 2015
Tuesday, January 6, 2015
Continuously delivering beta versions
I used to think that beta versions are lame. I associated “beta” with poor quality and with pushing validation to the users instead of ensuring high quality internally, through test driven development, clean design and excellent engineering practices. Now we are in progress of making Mockito 2.0 and we are using betas...
Beta version makes it possible to continuously deliver incompatible changes, incrementally. It is high quality: all tests pass, new coverage is meticulously added. Since there are several potentially incompatible changes, it would be hard to implement all of them in one go. We need more time and we still want to deliver continuously. Betas to the rescue!
It makes me think why making a new major version typically involves relatively significant effort. Why isn’t a major version release as simple as it should be? In theory one can develop a software library with high focus on compatibility: deprecate features and APIs with replacements, avoid incompatible changes at all cost, etc. In this mode, releasing a major version could be as simple as removing deprecated code, turning on some new behavior, changing the default settings and that’s it. A few commits and a single push. In practice, it is never that simple. For example, it might be costly to keep old and new behavior in parallel so that it can be toggled in the next major version. In this case, the authors may choose to remove the previous behavior and implement a new one as a part of major version implementation effort. In some cases, it might be actually the best for the end user because he could get the new features faster.
It makes me wonder about developing a software library that is always backwards compatible. I’m afraid it wouldn’t work. It feels that breaking changes are needed from time to time. Otherwise, the development can be slowed down or even paralyzed. Old features, APIs may stand in the way of innovation. It may become hard to tackle new important and challenging use cases. Industry does change, competition is restless, going after new ideas and use cases is unavoidable.
Being always compatible is often impractical. Major version releases typically involve extra effort. The latter bothers me. I’m going to work hard to avoid that in future. Continuous delivery makes releases hassle-free part of every-day routine. Semantic versioning and focus on compatibility make major version releases somewhat challenging and totally interesting. Hassle-free major version releases, on a regular basis, indicate very mature continuous delivery model. I want to be there.
Beta version makes it possible to continuously deliver incompatible changes, incrementally. It is high quality: all tests pass, new coverage is meticulously added. Since there are several potentially incompatible changes, it would be hard to implement all of them in one go. We need more time and we still want to deliver continuously. Betas to the rescue!
It makes me think why making a new major version typically involves relatively significant effort. Why isn’t a major version release as simple as it should be? In theory one can develop a software library with high focus on compatibility: deprecate features and APIs with replacements, avoid incompatible changes at all cost, etc. In this mode, releasing a major version could be as simple as removing deprecated code, turning on some new behavior, changing the default settings and that’s it. A few commits and a single push. In practice, it is never that simple. For example, it might be costly to keep old and new behavior in parallel so that it can be toggled in the next major version. In this case, the authors may choose to remove the previous behavior and implement a new one as a part of major version implementation effort. In some cases, it might be actually the best for the end user because he could get the new features faster.
It makes me wonder about developing a software library that is always backwards compatible. I’m afraid it wouldn’t work. It feels that breaking changes are needed from time to time. Otherwise, the development can be slowed down or even paralyzed. Old features, APIs may stand in the way of innovation. It may become hard to tackle new important and challenging use cases. Industry does change, competition is restless, going after new ideas and use cases is unavoidable.
Being always compatible is often impractical. Major version releases typically involve extra effort. The latter bothers me. I’m going to work hard to avoid that in future. Continuous delivery makes releases hassle-free part of every-day routine. Semantic versioning and focus on compatibility make major version releases somewhat challenging and totally interesting. Hassle-free major version releases, on a regular basis, indicate very mature continuous delivery model. I want to be there.
Subscribe to:
Posts (Atom)