Self-Service Delivery
I remember the first time I experienced Heroku. The simplicity of deployment via git push heroku master was so elegant. It gave every developer the power to ship from a simple push. It was also a PaaS, so you didn’t need to ask anyone for infrastructure to run your app. There was no deployment script to write and no CI configuration to craft and test, thanks to pre-defined buildpacks. The assumption that apps were similar and could be built by standard buildpacks freed us from the need to define the build and deployment ourselves. We were free to focus on writing code, to develop and ship without needing permission and with minimal or no toil to deploy.
The experience as a developer was delightful and it empowered us. But then pesky requirements like support for more sophisticated architectures than a simple app instance, and more rigorous build, test, and deployment support reared their heads. PaaS fell short of the demands of most real world apps because it wasn’t flexible enough.
No matter, right? There was CI for that. Except, instead of a git push and then magic, you had to script the execution process, choose and configure a CI tool to run that for you, or ask for help from the team that owned it in your organization. Then you needed to write a deployment script, or ask the team that owned the deployment platform to do it. What replaced the autonomy to ship was the need to script and configure the tools and ask for permission and help.
If I have to ask someone for a new environment for development and testing, then that slows me down and it slows them down too.
What if we could achieve and expand upon that delightful developer experience for a more robust universe of applications? How can we get back that developer autonomy mojo and apply it to our modern applications and deployment platforms?
Self-Service Delivery is an approach that makes the tools necessary to develop and deliver applications available via self-service. It makes the actions we need to take as developers — starting, developing and shipping software — available as user-accessible tools, so that we can work at our own speed without getting blocked. By making actions automated and accessible, it’s easier to standardize configurations and practices across teams.
We need specific building blocks to enable Self-Service Delivery.
Convention over configuration
The same principle at the heart of your favorite framework applies to delivery. If we think of delivery phases in framework terms, each phase has a default implementation, which can be overridden. For example, if the convention is that Node projects in my team are built by running npm test, then I include a test script in my project. I don’t write the code that runs the script, nor tell my build tool explicitly to do so. The same is true for other phases of delivery. If a Dockerfile is present in my project repository, it’s a good bet that running docker build is in the offing. Why make me tell a tool that? Shouldn’t the delivery process know how to do that? If I have delivery infrastructure that provides the implementation for these conventions, then I don’t need to define it explicitly. It also means that we get consistency across projects in the team because the easiest way is the consistent way.
Automate and make accessible
A big part of enabling self-service is making existing capabilities accessible. If I have to ask someone for a new environment for development and testing, that slows me down and it slows them down too. I spend time creating a support ticket, or I email or Slack someone a request. Then, they have to triage and respond to the request. In contrast, if I can say something like create dev environment or create react app and the same process that would have been initiated manually by someone else is executed automatically (with appropriate access control), then life is better for all. I am not blocked, I am free to work, and the people responsible for running the platform and tools didn’t have to lift a finger. They automated away that toil for themselves and made it self-service for me. Win win.
ChatOps promotes autonomy
ChatOps is a powerful enabler for self-service because it offers information in the form of messages and notifications, and you can interact with those messages to promote a deployment, or close an issue. It also gives people a way to take actions via bot commands available in the chat team. Chat is an ideal interface for self-service because it is conversational and flexible.
PaaS showed an elegant experience to strive for. It is possible to achieve self-service delivery with modern stacks and tools, with the right capabilities in place. We started Atomist to take on challenging problems for developers, and unleash autonomy via self-service. Learn more at atomist.com.
