Hey there, I’m going to attempt to cover an extensive topic, which means I will gloss over the specifics in an attempt to keep it relevant to as many as possible, though I may use examples from my work to give context.
For those of you who do not hold a technical understanding of development workflow, the best way to think of this is to imagine building a house. DevOps will build the foundations (The server) and lay the plumbing (monitoring tools, services and vital capacity). The developer builds the house ontop of the foundations (the application); this is where DevOps and development work together as the developer may ask for additional services such as Redis (Caching service) and the DevOps engineer will plumb in the required service and pass the details of that service to the developer.
Communication and collaboration are the key to success here and will be principles that will get repeated throughout the cycle we will explore.
So, What is DevOps? This is quite hard to define definitively; each business depending on its requirements, will implement DevOps differently; in some cases, developers will take on those responsibilities as part of their role, and other times, like in my case, it’s a dedicated role where you take ownership of those responsibilities.
DevOps is a culture, a practice and a philosophy that, when you drill it down, is meant to break down silos between development and operations and increase the quality and speed of development.
A DevOps culture is about a shared understanding between developers and operations and sharing responsibility for the software they build. For instance, I will deploy the infrastructure that the application the developer is creating will be deployed to. I will need to work with them closely to tailor the infrastructure to their requirements and, in some cases, get involved in the development to ensure that the application will function correctly.
These roles before were done in isolation with minimal communication in some cases. An integral part of the DevOps philosophy is to enhance communication and collaborate with teams that traditionally work in isolation.
Let’s talk about the DevOps life cycle, which is where the practice comes in.
We plan, we have a brief from the client, and we now need to work with development to plot out what tools, technology, and processes will best suit the product or feature we are working towards. This can be infrastructure diagrams, frameworks, what the development cycle will look like and what environments will be required.
When the development will begin, and tests will be defined. This step is developer-heavy as it can involve the initial development of the application/feature. If this is on the second iteration of this lifecycle, it could be that you are resolving issues found in the previous iteration.
A DevOps engineer would provision the planned infrastructure, services and pipelines to give a clean way to develop an application upon.
The Testing phase is where the application is put through the written tests to check integrity, a bit like how as part of your peer reviews, you will demonstrate integrity via testing with tools such as PHPUnit, Jest, Behat etc.
The release is where usually a branch with all the features and fixes you have been working on is ready for deployment and has been through testing.
This is the exciting part; you get to deploy your code to a live environment, for example, dev or staging. You get to see how your code reacts when on the infrastructure, which is as close a copy as possible to what production will look like to remove any chance of issues when deploying to a live environment. This is done via a pipeline.
This is where the DevOps engineer looks at how the application reacts to the new infrastructure, making changes where required.
This is where we check performance, troubleshoot and share insights. You can expect to see tools such as Sentry, New Relic, DataDog, StatusCake, etc.
And then the cycle starts again! But with more complexity each time round as you get closer to deploying to production, QA testers possibly become part of the monitor phase and the client performing user acceptance testing.
I could go into the nitty gritty here, but I want to keep this high level to ensure it stays relevant to any environment you may find yourself.
Hello, Just a short thank you for taking the time to read my blog; I’m planning on doing weekly write-ups and covering topics across the DevOps and SRE space.
DevOps and SRE @ Cyber-Duck