DevOps - Part II

DevOps and roles in a startup

So in the last post, we covered what DevOps is and how the culture build around those ideas can be incredibly beneficial to us. Now I want to talk about those ideas more concretely and also define the tools that we can use to follow the principles of DevOps.

The first task in creating a culture is getting everyone headed in the same direction and working toward the same goal, which means identifying common ground for the team through it’s functionality and roles. A common set of tools allows practitioners to work anywhere, and new team members need to learn only one set of tools — a process that’s efficient, cost-effective, repeatable, and scalable: maybe PaaS is what can fill up this niche.

A DevOps team can have it’s members assume the following roles:

  1. Data Analyst(s): The purpose of this role is management of data obtained from any streams, it could be user-experience input, unit testing or in-person usability test. Fundamentally, through the analysts, the developers in a startup gain access to the outside world and constantly adopt new input into their frameworks.

  2. Software architect(s): The purpose of this role is to facilitate the startup with it’s core engineers who will form the backbone of product development for them.

  3. Integrations personnel: This includes the rest of the team. The purpose of this role is to integrate the data provided by the analysts into that which is being created by the architects. They have to quality check that every aspect of the developed application is in sync with customer development and also they have to ensure that the startup as a whole has flexibility to change or pivot to the demands of the market/clients.

It’s worth noting that I have purposefully left out positions like CEO or any other C-level positions and this is fundamentally for two different reasons: First is that creating C-level positions in a small team will definitely lead to hubris and related factors to play in which is devastating for any sort of progress. More importantly, everyone in the team needs to have a relatable role in the actual product development process and being able to break those walls that hinder communication is the main purpose of DevOps. We are trying to create a culture with an even playing-ground and a cross-functional team. This team can communicate effectively amongst one another and remove any friction to seamlessly focus on the most important task: Product Development.

With that being said, this cross-functional team needs to focus on the following goals:

  1. Develop and deploy in production-like systems.
  2. Release early and often.
  3. Monitor the deployed app’s quality and perform stress testing.
  4. Focus on creating larger feedback loops from customers.

Let me explain these in more detail, the first goal is in place to avoid production delays because of inconsistency in development environment and production environment. The second one is there to help you deploy iteratively which can be automated easily using tools that will be mentioned shortly. The third goal ensures that before release the team gets a really good idea of where the app stands in terms of performance and scalability, also the integrations personnel get the much needed feedback to focus on scalability in the future.  The last goal is there to create larger feedback loops to get a bigger pool of customer input on your product as you are reaching the critical stages before your release.

Virtual assembly line

It makes sense to think of software being developed as it is traveling down a sort of virtual assembly line where it is being developed by multiple people, one after another leading to the final product. This later on becomes the basis of new techniques that we will be describing in the following.

Continuous integration was made popular by the agile movement. The idea is for developers to regularly integrate their work with that of the rest of the developers on their team and then test the integrated work. The goal of continuous release and deployment is to release new features to customers and users as soon as possible to get valuable feedback and integrate it into the product in development. Continuous integration thereby reduces risk and identifies issues earlier in the software development life cycle.

Continuous testing occurs by adopting capabilities like automated testing and service virtualization. Service virtualization is the new capability for simulation of production-like environments and makes continuous testing feasible. This allows us to test even more abstract concepts such as the business vision or value, and then continuously adapting and adjusting based on customer feedback. In lean-startup, this is called build-measure-learn loop. New analytics technologies such as google analytics and Heap allow businesses to capture customer behavior and customer pain points right as they use the application. This continuous feedback loop is an essential component of DevOps, allowing businesses to be more agile and responsive to customer needs.

Pivot (change) management is a set of activities designed to control, manage, and track change by identifying the work products that are likely to pivot and the processes used to implement that pivot. Change management drives the way the DevOps processes absorb and react to change requests and customer feedback. This last role relies on integrating the data that your data analyst will be able to provide the founder(s) and together they can make those incredibly important decisions on when the products need to be pivoted to fit the market a little better.

The software as a virtual assembly line and the concepts of continous development are very nicely illustrated in this video visually. Stay tuned for more on DevOps and adoption to startups!