If I Can DevOps, So Can You – Part V : “Choppin’ broccoli…”

Now you’re cooking. Prep the ingredients, have your water boiling, measured out the spices. Now you’ve got to assemble it all into one, two, three or more dishes to serve a complete meal, and time the delivery to the customer in the right order. 

As an technology executive, you are leading your teams in laying out an initial feature and capability set for your MVP (minimal viable product), developing epics for the product lines, and figuring out how many sprints it’ll take to get there. You’re setting the pace and timelines based on this, adjusting your resource allocation and consumption to achieve this. But make sure it’s achievable, don’t think that substituting tofu for chicken and expect people not to notice, use the right tools and ingredients that are going to help reach your goal, plan carefully, execute thoughtfully. 

There’s plenty of tools to help with DevOps, whether it’s just a process issue, or actual technical tools which can be connected up to create a workflow to deploy and run your solutions. Selecting a source code management solution, to code quality and security checking, to build and deployment automation, to cloud orchestration, scaling and management is about balancing current needs with strategic plans to ensure all of them work together complimentary to go from raw keyboard entry by a developer to the interaction of end users seamlessly and smoothly.

Senior leaders, and some of the subordinate roles will be awash in marketing and claims about the completeness of their vision and maturity of execution for their tools, but to avoid unused capabilities or not looking comprehensively at their integration with other services they plan on consuming. If not, you’ll be slicing and dicing those ingredients to try to get them to fit, wasting a lot of your investment. Be measured and calculating, but don’t be so risk adverse that projects stall due to “analysis paralysis”.

The basic pieces of, what is, an automation deployment pipeline to act as the technical backbone will include a code and versioning repository, build, testing and release tools, and a deployment environment, which can be on premises (self hosted) or to a cloud platform. For the purposes of this blog series, the destination will be a cloud platform, but simply redirecting to a similarly provisioned host that supports similar services could lso work.

My ingredients started with the series of domain names, but will primarily be “AllTheOps.org” highlighting the “X” + “Ops”, hosted on Amazon Web Services (AWS) free tier, using GitHub for the code repository, and use several free open source or “community editions” of software or service packages to assist with automation of several steps and capabilities of a continuous integration and deployment pipeline. At first blush, this may appear overkill for a basic website, but using this backend to do simple workflow modeling, such as for a website authoring and publishing will remove some of the higher level complexity of debugging code and more of the implementation mechanics.

I will also perform or act as most of the team roles, but will also leverage some of my peers here at my employer to play other parts of the development and product management team where applicable. Those points where I need customer and user feedback, I will collect that iteratively much like you would in a larger activity from you, the readers. Plus, as we continue this series, each of these posts can and will be updated, in the practice of versioning and iterative improvement, by feedback and comments. In some cases, for some topics we will branch into side discussions and sections providing deeper dives into certain aspects of this project to allow those who want to dive in more detail.