Search for a command to run...
Well, I worked as:
No comments yet. Be the first to comment.
Revisiting my Top 5 project ideas from May 2022 and my next Top 5 before Summer hiatus
Over my last three posts, I have shared some of my k8s anecdotes, detailing my experiences surviving since last Christmas. In this concluding entry of my adventure series, I aim to bring closure to this chapter of my k8s journey. Within this blog pos...
Introduction True, my hate/love relationship with k8s is still going on, but I've to say, that all in all you can learn a lot, even if you don't use the know-how daily at work. For me, it gives me an understanding of what my developers and ops people...
... In the last part, you could read about the beginning of my k8s journey. The rescue of my Monitor Raspberry Pi, and the build of my 5 Raspberry Pi k8s cluster. Also the basic setup with DietPi OS. In part II, I want to show how I did the k8s setup...
So, a new year, and a lot of time to continue some adventures over the Xmas holiday break. After the usual visit to my family's place, I came home and was surprised with a broken k8s cluster. So I thought. But after some investigation, I found out, t...
... as a web developer at a huge online service provider company, the one who flooded your mailbox with CD's of their online software. My responsible back then was the german sidebar of the other Internet Browser - as Microsoft would have called it - which belonged to the OSP, I was working for.
Our team consisted of me, as dev, a web project lead as responsible product owner, a tester and a webmaster - yes back then they where called that - as a small cross functional team. Sounds familiar, thats what you nowadays have in a DevOps team. But that is a different story.
Ok, so I was coding the sidebars for finance, news, sports and other stuff in a neat little pearl framework which created jsp pages. As usual coding was done on a local machine. When I was finished, I had to book time on a test machine, to run it on a production like environment. Isn't that what you want nowadays, too. Not the booking part, I mean the production like environment as a testing rig.
Anyway, deployment was done, of course by hand, the old fashioned way, with scp over ssh. Coping the files to the right location and then accessing it with the test url in the browser. When you were ok, with it, you gave the tester a call to run their test and report the result, may it be a bug or an Ok. This could often take days. But when you got the Ok, your work as Dev continued to make a release file.
Oh, the glorious release file. It was nothing more as a zipped file with all the files which needed to be deployed on the production servers. And have I mentioned, that it all was done by hand. This release file then was uploaded to a ftp server which was accessible in the production environment. Then you sent an email to the webmaster. And then the waiting game begun again. Because your responsible webmaster was not always available for your project.
But when the webmaster had time and was working on your project, he deployed your code to the staging environment, where it was tested again, by the tester, the Web PL and the webmaster. If all three agreed, it was Ok, it was published or better copied to the production servers. Of course at a scheduled time, when almost no traffic was on production servers. That was the way it was done back then, with all it problems you could imagine.
For me this was always a broken and inefficient process. Back in 2000/2001 we used CVS as code versioning system. So after doing some "Releases" the old fashioned way, I pitched an idea to my boss. Why not use a CVS repository in a secured space in the production area, were the devs could upload the released code and from there it could be deployed to all systems from a central point. Always the same code, always the same version, no mess up of files or versions.
My boss and the responsible for the production environments agreed to do a PoC. Of course I choose my sidebar project for it. After w few month everything was in place. CVS was running in production in a secure area. It was accessible for the devs and for the webmasters.
So I started using it. I uploaded my first new release to this new "release" CVS. Then it was time to deploy it to the test environment. Of course booking a test slot was still needed, but I could the first time use a bash script, which was written by my webmaster, to check out the code from the CVS and place it in the right location, with one command.
Ok, testing was still done manually. Remember Selenium) wasn't invented back then. Our tester did some scripting and screen recording for testing, too. But it was very basic. So most of the testing was done by hand. So the process was still the same. But after the Go, the webmaster, which used the chance and automated the process in the production environment, too. Could simply call his script and my released code was deployed first to the stageing environment, and later - scheduled via cron job - to production.
After a few releases and fixing some small challenges, we showed it to the IT management, and they liked it, and it was introduced to all web projects which where done in Germany.
So we introduced something in 2001 which is nowadays is the goal of GitOps. Ok, it was not exactly GitOps what we did back in 2001. It lacks a lot of things what makes GitOps to GitOps. First of all we didn't use Git. Well, Git was released in 2005. Then we do not use automation and CI/CD. Ok, automation we did use a little bit with the bash script and the help of a cron job, but no CI/CD at all.
Of course CI/CD was a new concept, at least we (in our company) in Germany back in 2001 hadn't heard from it. And when you check Wiki for Hudson) (predecessor of Jenkins) ) it was released 2005, so it was simply not available for us back then. Also automated testing was not done or done only rudimentary. And finally the concept of infrastructure as code was also not present or at least not in that way.
I still think it was pretty neat what we've done that. But I leave it up to you if you consider us pioneers back in 2001 for a GitOps-ish thing we did.
Well next week I tell you a story about bots...
As always apply this rule: "Questions, feel free to ask. If you have ideas or find errors, mistakes, problems or other things which bother or enjoy you, use your common sense and be a self-reliant human being."
Have a good one. Alex
