Redacted from Source.
Feel the magic
For most firms there is little magic in Dev-Ops. Mostly buzzwords. As with ‘Agile’, tepid use of Dev-Ops does not mean you have ‘Dev-Ops’. A 9 am ‘Scrum’ meeting does not mean you are ‘Agile’. Someone in the corner playing with Terraform does not mean you have ‘Dev-Ops’.
Dev-Ops is apparently, the combination of development and operational support on one team. It essentially means that if you build it, you own it and manage it. It will likely include:
-Use of automation tools throughout the ‘pipeline’ of code creation and testing, through to code branches, trunks and repositories, onto deployments and continuous integration, continuous delivery and Infrastructure as Code or IaC
-Integrated testing and rollback are mandatory
-The process can include both the deployments of standard Virtual Machine stacks, as well, as Micro-services
The Use Case for the Magic
Importantly: the product being made must be long-lived, have changing requirements and be associated with a target market and business plan. If you are deploying a new version every year or two, you will not need an integrated Dev-Ops team, though one of course helps simplify even this process, but it would not be mandatory given that the use-case is quite different from a process in which you are constantly deploying changes and updates.
Long-lived products which face a consumer client (eg. a mobile-banking app), lend themselves to ‘digital’ processes and tooling as well as integrated Dev-Ops processes. An internally facing application with the same number of users and processes year over year, does not need Dev-Ops, given that feature and version changes are few.
How does DevOps work?
DevOps is a process to help professionalise the SLDC which includes: plan, code, build, test, release, deploy, operate, monitor and — through feedback — plan, which resets the loop. To build this pipeline you will have an integrated team of developers, operations, security, testing, SMEs, an Architect and the Business – all on the same team, all communicating and clarifying the business requirements and translating them into technical delivery based on Agile sprints and Agile engineering. A heavy emphasis on tooling and automation is assumed, and these will depend on your target platform model.
To create consistency, you will deploy configuration management of your accounts making them similar (Dev, Test, Prod). All Cloud platforms provide templates for this. The environmental setup is matched by the use of templates to deploy infrastructure to support the built applications. This is called IaC and is based on YAML or JSON templates. Your entire set of deployments should be built on patterns (type of application stack) and required underlying infrastructure (IaC).
Business Involvement
A Business owner must be inside the Dev-Ops, Agile team to resolve the inherent friction between the Business and IT. Most IT people (and many Busines people) do not understand the Business requirements, the domain language (eg. banking), or end user expectations. Over time, iteratively, a combined team will refine these to build systems which fulfil the objectives for both IT and the Business. Importantly the deployments are into similar environments, so the excuse ‘well it ran on my box, or in dev…’ should not apply when the prod deployment is made.
DevOps vs. SRE
Site reliability engineering arose concurrently with Agile and DevOps. Started in the early 2000s at Google, it is essentially a programming- and automation- focused approach to the software development lifecycle. Problems should be solved in a way that prevents them from occurring again. Rote tasks should be minimized.
The SRE toolbox closely matches that for DevOps. Both disciplines aim for continuous improvement. SRE and DevOps engineers seek to abolish silos between development and operations. While DevOps also can extend to business stakeholders, SRE typically stays within the confines of IT processes.
Issues with DevOps
Most firms put a few people into a corner playing with CI-CD or IAC and declare themselves a DevOps organization. DevOps must be combined with Agile, it would make no sense to use Waterfall given that DevOps must be an iterative, collaborative approach, focused on outputs and quality, not stage-gates and meetings. This of course is a big cultural and organizational jump for most firms. Some issues with DevOps:
1-Business is not involved
2-Agile not used
3-Agile used but not understood
4-No standardisation of tooling, automation
5-No standardization of databases, code and frameworks
6-Limited skills, understanding of the target platform
7-Waterfall budgeting vs. Agile funding
8-Organisation and cultural changes
9-Poor IT skills in Dev and Ops groups (no training, certs)
10-No code strategy or single repository
11-No use of Artifacts for testing, version control (compiled code)
12-Security, Monitoring, Reporting are not designed up-front into deployments
DevOps is hard
Dev-Ops has many moving pieces, most of them firmly connected to your platform of choice. Agile must be used. So, start small. Understand the entire end-to-end process. Prove the ideas. Focus on automation and business requirements being fulfilled. Training is mandatory as is time. It may take months or longer, for a team to fully understand DevOps and Agile including the use of communication tools such as Jira and Confluence.