DevOps: Continuous Everything
DevOps: Continuous Everything
This author proposes adding a concept of continuous programming to DevOps, automating the creation of features associated with user stories.
Join the DZone community and get the full member experience.Join For Free
DevOps brings the word "continuous" to the center stage of agile development in the form of continuous integration, continuous testing, continuous delivery, continuous deployment, and continuous operations with a focus on delivering continuous value to the customer, faster!
In today’s market, if you have a great idea for launching a successful product, rest assured that the first one to launch captures almost 80% of the market pie. How many of us remember Buzz Aldrin? He was the second person to set foot on the moon after Neil Armstrong.
Without the implementation of DevOps practices, companies cannot survive in today’s fierce competition and tomorrow’s cut-throat battle. It is an absolute necessity for companies to invest in DevOps and walk the walk of DevOps principle and practices, in every nook and corner of the company. Companies who have focused on DevOps as part of their strategic intent have significantly accelerated the time from ideation to implementation. Companies such as Netflix, Google, Amazon, and Facebook are pioneers and leading the way. Realizing the benefits of DevOps, most of the federal agencies have now embarked on the DevOps journey; some are further ahead and some are catching up, but we can see a DevOps movement has begun and it’s a good thing.
Today, I would like to bring forth an area in DevOps which is not much discussed. Some might also say it is too utopian, but I would respectfully argue that we are living in an era where what we believed to be a fiction yesterday has turned into reality today.
I would like to see "continuous programming" added to the idea of continuity within DevOps. Imagine, once the user stories are committed to the backlog, the software builds the feature associated with the user stories by itself without any manual intervention. You must be wondering even if this is feasible; what happened to the role of the developers? Well, there will be a principle shift in the role of developers from "feature coder" to "library builder and recipe maker." Developers will work on creating various libraries and the recipes which will then be available to the automated builder, which will use these libraries as a building block and follow the recipe to develop the features. I envision this tool similar to the role of a painter who will use the color combinations created by the developers (palette) and instructions on how to create the paintings to actually create the paintings. With this approach, developers are focused on creating libraries and instructions, and the software is performing the role of an orchestrator to build the features.
The library can include binaries, services, templates, frameworks, reflections, rules, technology, and infrastructure stacks, which are written independently of each other and are tool agnostics. The recipe will provide the steps on how these library items will communicate with each other, what language will be used, what rules will need to be applied, etc. The software as an ‘Automated Assembler’ will follow the steps laid out in the recipe and will pull the items from the library and assemble the features. The recipe can also include instruction for creating integration hooks on quality, security, and accessibility, and the software will pull the appropriate binaries while building the features.
The developer’s role will focus on building a library of components. The library items can be developed with the primary vision of "development for reuse;" these will be independent and reusable components. The recipe will also be developed by the developers based on the user specifications and requirements; these recipes will provide the instructions on how the components can be used. The automated assembler will require the intelligence to assemble and orchestrate the components using the instructions in the recipe and build features. As you can see from the figure above, the automated assembler is decoupled from the developers and should function intelligently to spin up features. The buck does not stop there; the feature, once certified, will be added to the library for building other features on top of it.
"Continuous programming" brings forth the idea of decoupling the "code to build a feature" to "code to build the feature itself" by breaking down the development into "development for reuse" and "development with reuse." In doing so, developers are investing in creating a habitat in which the automated assembler can learn and evolve and continuously improve. Continuous programming can significantly reduce time to market and shorten the feedback loop by creating transparency upstream on the DevOps pipeline and incrementally improving after every feature build.
Continuous programming would be a great value addition to the complete DevOps pipeline, as it will allow developers to focus on building recipes and components and move the intentional programming aspect to the automated assembler, which can automate the generation of source code.
Spread the DevOps virus in the organization and once it works out the kinks, evangelize the approach to the rest of the organization.
Opinions expressed by DZone contributors are their own.