DevOps is a highly collaborative way to create value for your customer. We like to see it as a next logical step towards reaching a higher maturity level of your software development process. Small increments often help to increase the quality of products, enable a faster time to market and a better return on investment. Typical DevOps drivers are; wanting to increase time to market, wanting to decrease variations in product quality. Or getting good measurement of (the quality) of your process. The interlinking elements of DevOps are captured in CALMS; Culture, Automation, Lean, Measurement & Sharing.
We would like to support you on your journey towards DevOps and help you build a solid Agile Foundation for your company.
Culture is not something you implement; it is the natural environment that houses the entire development team. Entire means all the developers, QA, AND operations. In this eco-system of people and tools, the culture is necessary to remove barriers and facilitate collaboration to hit team objectives. Read More
Once you have culture in place you can focus on automation. This is not just creating scripts for infrastructure or using Selenium for functional testing. Automation is the idea that you should program everything. Find a way to lead all new initiatives with automation and then think about automation constantly to help scale. Read More
As you build automation you also have to remember to be lean. Running lean means keeping optimizing your process on a daily basis. Tools, meetings, and even sprints should all be kept lean. It also applies to your teams. Keep teams to an effective size to avoid diminishing returns. If the application complexity warrants larger teams, break them into sub groups, as many large organizations have done. Read More
Measurement is the glue that keeps it all together. When you are a lean organization automating everything, you can lose the ability to remember and document it all. If a team does not have visibility into everything, something will eventually go horribly wrong. When measurement is implemented correctly this should not happen. If you measure everything and think in terms of reporting on your development team and processes, you will have the ability to analyze and correlate all processes, tools, and production data together. Read More
With all this data, you need to disseminate what is learned, what went wrong, and how to correct. The benefit of breaking down the walls between developers and operations is the information flow becomes bi-directional, and you avoid the concept of “throwing things over the fence”. However, this is worthless if information is not shared proactively. Sharing is not just reporting facts, it is regularly exchanging ideas across teams. Read more
Other relevant DevOps content
- BLOG: Red Hat – OpenShift Day-2 Ops from the trenches
- REPORT: 2018 State of DevOps Report – DevOps Research Assessment
- OFFER: DORA – DevOps Research and Assessment
- BLOG: Observability in OpenShift with Prometheus
- WHITE PAPER: The Digital‐Native Enterprise – The Red Hat and Devoteam Success Formula
- BLOG: Shared continuous delivery toolchain, the silver bullet?
- NEWS: Atlassian Gold Solution Partnership for Devoteam
- INFO: Our CALMS approach towards DevOps
- CASE STUDY: Improving the CIO delivery cycle at Liberty Global
- BLOG: Monitoring to reduce Mean Time To Recovery (MTTR)
- EBOOK: API Strategy and Architecture
- EBOOK: DevOps Perspectives
- OFFER: DevOps and Culture
- OFFER: Continuous Delivery
- CASE STUDY: Same meat, different gravy
- BLOG: Become a high performing organization with DevOps as business enabler