Many many many years ago, I learned to program. It was on a Radio Shack Color Computer. It had a BASIC plug in pack and I think I could save to a cassette tape. I followed the BASIC programming book and learned to write code. My very first program was one that let you create a vehicle for Steve Jackson’s Car Wars. Heck, I was fortunate to discover the old BASIC program in an old backup CD from the 90’s and it’s now in my github repository.
My first couple of jobs after getting out of the Army in 1982 were programming related in one way or another. But I moved away from being a developer and into building local area networks (LANs) and writing scripts and programs to help with that. It let me be creative without the restrictions that came with writing code professionally.
In the mid-90’s, I switched from managing LANs to managing Unix servers. Solaris primarily but some HP-UX, Irix, Tru64, and Red Hat Linux. This exposed me to the real basic Revision Control System (RCS) that we used to manage configuration files on the Unix servers.
I began using RCS for my personal programming projects. Many years later, I wrote an Inventory program to help manage our servers. I of course used RCS to manage the changes. I had my own way to deploying finished code to production systems, similar to how Jenkins works if you’re familiar with that tool. In order to become familiar with current tools, I gradually shifted over to git.
It’s been an interesting run and now I’m working directly with developers and it’s giving me a better understanding of their needs. Because I want to help them do a better job, I’m learning their techniques and applying them again to my projects. I’ve set up a much better Jenkins pipeline and even used gitlab’s CI/CD pipeline.
Because we’re using git and github a lot more with the new job, I’m a bit more knowledgeable about development practices. One of which is branching. A release branch, development branch, feature branches, and hot-fix branches.
For our automation practices, doing much more than a main branch and a feature branch is probably over kill. We aren’t writing code, we’re creating automation and at times, need a much quicker turn around to get changes applied so we can continue with the task.
But for my personal stuff like my photo library, inventory, and other programs, I can take advantage of what I’m learning and apply it there.
I don’t have everything following this technique but the main programs are gradually migrating in that direction.
For my environment, I have two configurations. An environment that’s similar to a work setup where I have a development, QA, staging, and production pipeline. And my personal environment where I have a local installation, one for my docker work, and one for my remote or production like environment.
For each environment, I have a couple of development like servers. One with website development and one with more utilities and playbooks.
As for the pipeline, each of my programs has a Main or Release branch, a Development branch, and under that, Feature branches. In Jenkins, I have a trigger for the local or development environments that is based on the /dev branch. When I create a feature branch, when I merge it in, it’s merged with the dev branch. This then triggers the testing and deployment to my local development testing servers (bldr0cuomtool11 and ndld1cuomtool11).
When I’m ready to create a Release, I merge dev with the main branch and in Jenkins, the Docker and Remote servers are updated for the home environment. For the work like environment, code is deployed to the QA and Staging servers. The final deployment to Production is manually executed by me to simulate a live corporate configuration.
I like this process. My first stage is testing and if that passes, deployment to be reviewed. Then a release is created and the pipeline is followed. Pretty interesting.