CONTENTS

• INTRODUCTION
• ROLES AND RESPONSIBILITES
• DAY TO DAY ACTIVITES
• CICD PIPELINE
• BRANCHING STRATEGY
• DEPLOYMENT TYPES
• DAILY BUILDS
• QUESTIONS

INTRODUCTION
I started my career in 2020 with Maxipi Technologies as a DevOps Engineer, where I was part of the product engineering
team. That’s where I built my foundation in CI/CD automation, AWS, and containerization. Most of my work was
around setting up jenkins pipelines, automating deployments, and helping developers release faster without manual steps.
I also learned how to manage Kubernetes clusters and I have used Bash and PowerShell to automate deployments and
worked on HashiCorp Vault for managing secrets. Those early years really helped me understand the full release lifecycle
and cloud infrastructure basics.
After about three years, I moved to Syncrasy Tech in 2023. This was a consulting style role where I worked across
different client environments. I worked on AWS, EKS, GitLab and Docker. I also built compliance dashboards with
Python, Prometheus, and AWS Lambda, which helped clients speed up SOC2, ISO 27001, and GDPR audits. That’s
also where I started applying SRE practices — introducing SLOs and SLIs, running postmortems, which gave me good
exposure to reliability engineering.
Then I joined eCOMM Merchant Solutions, a FinTech SaaS startup based in Ireland on contract role. I managed large
scale AWS infrastructure — including VPC, IAM, EC2, S3, RDS, and Lambda — and automated infra provisioning
with Terraform and Ansible. I implemented GitOps workflows using Argo CD and Helm, integrated DevSecOps gates
into Jenkins pipeline using tools like SonarQube, Trivy and even automated vulnerability reports using Python scripts.
On the observability side, I built full monitoring and alerting using Prometheus, Grafana, Dynatrace, and ELK. Worked
creating reusable incident runbooks for on-call support.
Overall, my career has grown from setting up basic pipelines and automation to handling complete DevOps and Site
Reliability Engineering responsibilities
That’s a brief overview of my background and experience.
.....................................................................................................................
ROLES AND RESPONSIBILITES
• Start the day by checking monitoring dashboards in Prometheus, Grafana, Dynatrace and ELK to make sure
systems are healthy.
• Handle any critical alerts or incidents on priority to maintain platform stability and 99.9
• Work with Jenkins, GitLab CI, and Argo CD to automate deployments and manage release pipelines.
• Write and maintain CI/CD scripts, integrate security scans like SonarQube, Trivy, and OPA, and ensure smooth,
secure rollouts.
• Build and manage Docker base images and keep them CIS compliant, reducing vulnerabilities by around 80
• Use Terraform and Ansible for provisioning and managing AWS resources like EC2, S3, VPC, and IAM.
• Regularly patch systems, renew SSL certificates, and ensure compliance with PCI DSS standards.
• Monitor performance metrics, optimize autoscaling and database queries to improve speed and cut costs.
• Maintain observability dashboards and runbooks to reduce response time during incidents.
• Participate in daily stand-ups, deployments, and on-call rotations, supporting smooth operations and quick recovery.

DAY TO DAY ACTIVITES

• I usually start my day by checking Prometheus, Grafana, and Dynatrace dashboards for alerts or production
issues.
• Then I check emails and tickets for any critical issues that need quick attention. If something looks urgent, I fix
that first before moving to planned tasks.
• After that, we have our daily stand-up call where we discuss current deployments, blockers, and what each team
member is working on.
• Most of my day goes into managing deployments — I use Jenkins pipelines or Argo CD GitOps to deploy
updates to staging or production.
• I also keep an eye on pipeline runs to make sure builds pass all security and compliance checks, like Trivy and
SonarQube scans.
• During the day, I handle AWS management tasks — creating or updating EC2 instances, S3 buckets, IAM
roles, and sometimes writing or updating Terraform and Ansible scripts.
• I regularly check system performance metrics, adjust autoscaling policies, and do small optimizations to
improve response time and reduce costs.

1
 • Whenever there’s a deployment issue or alert, I coordinate with the development and QA teams to trou-
bleshoot and fix it quickly.
• Towards the end of the day, I usually update JIRA tasks, join our evening sync-up call, and plan next day’s
priorities.
• If I’m on-call that week, I stay available to respond to critical alerts and make sure production stays healthy 24/7.

CICD PIPELINE
1. Stage 1: Code merge and trigger
• Once a developer’s code (PR) is reviewed and merged into the main branch, GitHub automatically sends a
signal (webhook) to Jenkins. That signal starts the CI pipeline.
2. Stage 2: Source code analysis
• Jenkins first runs SonarScanner on the project.
• It checks the code quality using SonarQube — if there are too many issues or the quality gate fails, the pipeline
stops immediately.
• Developers can then open SonarQube to see bugs, vulnerabilities, or code smells and fix them.
3. Stage 3: Build and package
• Jenkins checks out the latest code.
• It compiles and creates a package like a .jar, .war, or .ear file depending on the project.

4. Stage 4: Build Docker image

• Using the Dockerfile, we create a Docker image from that package.
• Image is tagged with a unique Git commit ID and version number.

5. Stage 5: Push to Harbor

• Image is then pushed to Harbor, which is our container registry (like a private Docker Hub).
• Harbor also scans the image for vulnerabilities using Trivy, to make sure it’s secure.
6. Stage 6: GitOps (No kubectl from Jenkins)
• Jenkins never directly talks to the Kubernetes cluster.
• Instead of using kubectl apply, pipeline updates a separate Git repository (called environment repo).
• Each environment (Dev, QA, Stage, Prod) has its own folder or configuration.
• Pipeline simply updates image tag in that folder and creates a pull request.
• (If someone asks what env-repo looks like:) It has a base configuration and overlays like dev, qa, stage, and
prod. The only thing that usually changes is the image tag or a few environment-specific settings.

7. Stage 7: Deployment with Argo CD

• Argo CD continuously watches that environment repo.
• Whenever it sees a change (like a new image tag), it automatically updates live Kubernetes cluster to match
what’s in Git.
• Argo CD also auto-heals, meaning if someone makes a manual change in the cluster, it rolls it back to what
Git says.
• This way, Jenkins never needs direct cluster access or credentials.
• Argo supports Helm, Kustomize, and plain YAML, and has a nice UI.

8. Stage 8: Environment promotion (Dev → QA → Stage → Prod)

• Moving from one environment to another is simple — it’s just merging the next PR.
• For example, after QA testing passes, we merge the next PR to move from QA → Stage → Prod.
• Argo CD then syncs each environment automatically, keeping a clear Git-based audit trail of every deployment.
9. Stage 9: Safer rollouts
• For gradual or canary releases, we use Argo Rollouts.
• It helps us do blue/green or canary deployments.
• and also manages traffic shifting, monitoring, and rollback.
• Everything is still controlled through Git.

10. Stage 10: Testing and feedback

• After every deployment, QA runs automated and manual test suites.
• If something fails, we can easily revert the Git commit to roll back.
• Argo’s UI clearly shows the current state, desired state, and sync history.
• This makes troubleshooting fast and simple.

2
BRANCHING STRATEGY
Main Branches:
• main: Stable production-ready code; protected from direct commits.
• develop: Integration branch for feature development.
Feature Branches:
• Created from develop for new features; named feature/feature-name.
• Merged back after code reviews and testing.
Bugfix and Hotfix Branches:
• Bugfix: For non-critical bugs in develop; named bugfix/issue-description.
• Hotfix: For critical production issues; named hotfix/issue-description;
“merged into main and develop.
Release Branches:
• Created from develop for release preparation; named release/version-number.
• Allow final testing and adjustments before merging into main.
Code Reviews and CI Checks:
• Mandatory merge requests with code reviews.
• Automated tests and checks must pass before merging.

DEPLOYMENT TYPES
We use three deployment strategies:
Blue-Green Deployments:
• Maintain two identical environments (Blue and Green).
• Deploy new versions to the idle environment and switch traffic after validation.
• Benefits: Zero downtime, easy rollback.
Canary Deployments:
• Gradually roll out new versions to a subset of users.
• Monitor performance before full-scale release.
• Benefits: Risk mitigation, real user testing.
Rolling Deployments:
• Update instances incrementally without taking the system offline.
• Benefits: No downtime, issues detected without impacting all users.

DAILY BUILDS
On average, we perform:
CI Builds:
• 20-30 Builds per Day:
– Triggered by code commits to provide immediate feedback.
Integration and Merge Builds:
• 5-10 Builds per Day:
– Occur when merging feature branches into develop.
Staging Deployments:
• 2-3 Builds per Day:
– Builds for the staging environment for testing.
Production Releases:
• 1-2 Builds per Day (as needed):
– Final builds deployed to production after approvals.
Total Builds per Day: Approximately 30-40 builds.

QUESTIONS
From your perspective, what would success look like for someone stepping into this role in the first 6–12 months? What
kind of impact would you hope they make? That’s really helpful — it gives me a good sense of priorities.
You’ve probably spoken with quite a few candidates for this role — based on our conversation, where do you think I
could improve or focus more, whether technically or in approach?
thanks, feedback, I’ll definitely work on it.