I’ve decided to learn more about DevOps.
I’ve always been a believer in automating repetitive tasks and letting machines do as much of “my” work as they can. The way I learn best is (as you can tell by the name of my blog) I learn about the topic, I build something from what I’ve learned and I share my experience.
Given that DevOps is a very big topic, it will take more than one or two posts to do it justice. This post is the first in a series of blog posts, videos and presentations that I plan to create as I learn more. I think the best place to start is with what I “think” I know now.
What is DevOps?
A couple years ago I was using Jenkins to create a continuous delivery pipeline for a project I was working on. I was the only one working on the project and after seeing a CD demonstration at a conference I figured I’d give it a try. I had everything working and I was quite pleased with myself. Then I started hearing the term DevOps and assumed it was just a term for what I was already doing. I was partially right.
DevOps is more than just automating the software delivery process, it’s also a cultural mindset. It’s developers and operations working together throughout the full lifecycle of a project instead of in separate silos. Since I was working solo on that project I missed out on this aspect. Currently, I’m not working on any project where I can experience the full cultural aspect so I plan to mentally assume different roles as I work through the learning process.
If you’d like a better definition, there is plenty of material available on the web from real experts. I only wanted to document what DevOps means to me as I start to learn more.
My current plan.
I have been working on an open source application used for demonstrations and learning called DinoDate. I am going to build a DevOps process around this application. I will be building this process using the Oracle Developer Cloud Service against an Oracle Cloud Database and other Oracle Cloud services, as well as other tools such as Jenkins against an Oracle Database on a VM.
Plan Steps:
- Define the steps to manually deploy DinoDate as is.
- Automate the build and deploy process which currently is, run some scripts and scp the code to an Oracle Compute instance where I have already setup Python and NodeJS.
- Deploy the NodeJS and Python apps to an Oracle Application Container Cloud instance.
- Add some open source tools to improve the process.
- Build script using Gradle.
- Schema object version control using Liquibase.
- Unit tests for the PL/SQL using UTPLSQL.
- Automate creating the infrastructure (DB, Compute instance) from scratch then deploy, test and destroy.
- Reproduce the entire CD pipeline using Jenkins (or another tool) against a VM.
Once I’m satisfied with my understanding of the tools and workflow, I’ll find a project that would benefit from a DevOps environment and pester encourage them to switch to a DevOps process with an offer to act as the DevOps “expert”.
More to come.
Keep an eye out here and on my YouTube channel for how-to and ‘lessons learned’ posts that I’ll make as I go. Feel free to post a comment if you see that I’ve already got something wrong or if you have a specific interest you’d like me to focus on as I go.
This post was originally published on learncodeshare.net
Top comments (3)
DevOps seems to be something you find yourself doing if you're the most experienced developer working in an underfunded team... 😉
I guess it depends on the Org. However, DevOps is not really a role, or something that somebody does; it is a culture.
Unfortunately, budding engineering teams in startups don't have money to invest on it. The tooling is still rough, and much work is necessary to set things up correctly. Teams in the early stages are too busy building a product to become obsessed about DevOps practices (unless the team members are already experts, which is rare at this point)
For established teams, it is difficult to quickly change ways things work, so organizations often hire someone with a "DevOps" title to bring-in the discipline and get things started. Eventually, it is not something somebody "does". It is something that is part of how everyone does things. It is a "how," not a "what."
DevOps considerations have to be built-in the way the software is designed. It is an all-encompassing culture that allows engineering teams to scale without having to scale a technical operations team linearly with the development team.
I absolutely get what you're saying about the team culture. And it's not something we've quite cracked in my team yet.
There is still a Dev Ops role though, particularly when it comes to Linux. There is a great deal of knowledge and skill required to set up environments, manage permissions, security, etc, etc. This is generally focused in an individual or individuals because it requires focus and dedication to learn properly. Also a lot of Devs are quite happy for someone else to handle it for them.
That's not to say a whole team's knowledge and skill can't be improved generally in this area though.