My DevOps Learning

Hello--

This is supposed to be my first article in LinkedIn. In fact, I was thinking for several days to share my thought process on different technical challenges during my career path but every time I went back of thinking that my article will be a needle in a haystack or maybe getting lost among other technical writings.

But finally, I got the courage, in fact today when I deliver the CI-CD solution for one of our clients, I lists down all the technical challenges faced by me while working on the overall approach.

The idea behind sharing this is not about sharing my accomplishment rather to get feedback from other people on what they think could have been a better approach so the entirety of this findings become a learning for me.

Let’s begin with my experience on designing CICD process using DevOps tools.

Understanding the Goal:

1. I found that understanding the current Release process and the to be process is the most important part of this project.

2. Understanding the to be Release process from the developer’s point of view is equally important than release manager.

3. It is very important for the architect to get into the shoes of the developer to understand what are the roadblocks they are going to face when the actual CICD process will become operational.

4. Both client and developers’ viewpoints need to be finalized before the design starts.

Understanding the technology stack and any limitations:

1. While most of the DevOps tools are opensource while some licensed version and even docker manager containerized instances are also available on the market. A proper analysis with pros and cons needs to done before starting the design.

2. In certain cases when build process is designed in Jenkins it may happen that the build needs an external toolkit library reference for executing commands. For example, creating a BAR file, overriding and deploying it will require IIB 10.0.0.7 toolkit installed on the server.

3. While executing the command if the toolkit exists on different OS then the build process should be able to execute across multiple OS. For example, Jenkins is running on Windows but Broker server is on Linux server. So, Jenkins will need SSH access to Linux box to execute any command.

4. There are multiple plugins available for Jenkins on the market, a proper research is required to understand which all plugins will be required. Extra download of plugins gives Jenkins performance issues.

5. Jenkins pipelines accepts both declarative and normal scripting. Normal scripting is not able to understand the

external variables getting passed from External sources to Jenkins pipeline Job. This issue gets resolved using declarative scripting.

That’s all folks. I will probably add more if these is helpful for others.