CI\CD on Brian Braatz Blog

Python + C# Microservices in AWS -Bitbucket, Bamboo and Octopus

Wed, 04 Dec 2019 00:00:00 +0000

Python Microservice in AWS with Bitbucket, Bamboo and Octopus

In this glorious adventure, we’ll:

Build a simple microservice in Python and C# that divides two numbers.
Package it up and deploy it to AWS using Infrastructure as Code (IaC).
Set up a CI/CD pipeline to automate the deployment using Bitbucket, Bamboo, and Octopus Deploy.

Step 1: Build the Microservices

Python Microservice 🐍

Let’s keep it simple with FastAPI, because who has time for Flask boilerplate?

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


from fastapi import FastAPI, HTTPException

app = FastAPI()

@app.get("/divide")
def divide(a: float, b: float):
 if b == 0:
 raise HTTPException(status_code=400, detail="Division by zero is not allowed!")
 return {"result": a / b}

if __name__ == "__main__":
 import uvicorn
 uvicorn.run(app, host="0.0.0.0", port=8000)

Run it:

1

uvicorn main:app --host 0.0.0.0 --port 8000

Test it:

1

curl "http://localhost:8000/divide?a=10&b=2"

C# Microservice 🤖

Now let’s write the same thing in ASP.NET Core.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


using Microsoft.AspNetCore.Mvc;

[ApiController]
[Route("api")]
public class DivideController : ControllerBase
{
 [HttpGet("divide")]
 public IActionResult Divide([FromQuery] double a, [FromQuery] double b)
 {
 if (b == 0)
 return BadRequest("Division by zero is not allowed!");

 return Ok(new { result = a / b });
 }
}

Run it:

1

dotnet run

Test it:

1

curl "http://localhost:5000/api/divide?a=10&b=2"

Boom! Two microservices ready. Let’s move on. 💪

Step 2: Deploy to AWS with Infrastructure as Code (IaC)

We’ll use Terraform for this. Here’s a sample Terraform script to deploy an EC2 instance with Docker.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


provider "aws" {
 region = "us-east-1"
}

resource "aws_instance" "microservice" {
 ami = "ami-12345678"
 instance_type = "t2.micro"

 user_data = <<-EOF
 #!/bin/bash
 docker run -d -p 8000:8000 my-python-microservice
 EOF
}

Apply it:

1
2


terraform init
terraform apply

Boom! Microservice is on AWS. ☁️

Step 3: Automate with CI/CD (Bitbucket + Bamboo + Octopus)

Bitbucket Pipelines

Add this to .bitbucket-pipelines.yml to automate testing and building.

1
2
3
4
5
6
7
8


image: python:3.9

pipelines:
 default:
 - step:
 script:
 - pip install -r requirements.txt
 - pytest

Bamboo CI/CD

Create a Bamboo Plan.
Add a Build Step to run tests.
Add a Deployment Step to push to AWS.

Octopus Deploy

Create a Deployment Process.
Define Environments (Dev, Staging, Prod).
Add an AWS Deployment Target.

Key Ideas Table

Step	Description
Build Microservice	Python (FastAPI) and C# (ASP.NET Core)
Deploy to AWS	Using Terraform for Infrastructure as Code
Automate CI/CD	Bitbucket Pipelines, Bamboo, Octopus

Reference Links

There you go! 🎉 A Python & C# Microservice, AWS Deployment, and CI/CD Automation. Now go forth and divide… your workload! 😆

8 Unusual Things You COULD Do with Infrastructure as Code

Wed, 17 May 2023 00:00:00 +0000

8 Unusual Things You COULD Do with Infrastructure as Code

A Quick History of Infrastructure as Code

Before IaC, deploying infrastructure was like assembling IKEA furniture without instructions. Sysadmins manually configured everything, leading to errors, inconsistencies, and existential dread. 😵‍💫

Then, in the 2010s, tools like AWS CloudFormation (2011) and Terraform (2014) changed everything. Suddenly, you could define your entire infrastructure in code, store it in Git, and deploy it automatically. No more clicking around AWS like a lost intern.

1. Deploy a Minecraft Server 🎮

Why manually set up a Minecraft server when Terraform can do it for you? With IaC, you can spin up a dedicated EC2 instance, configure networking, and deploy Minecraft—all in a few lines of code.

1
2
3
4
5


resource "aws_instance" "minecraft_server" {
 ami = "ami-12345678"
 instance_type = "t3.medium"
 user_data = "#!/bin/bash\nsudo yum install -y java\nsudo wget -O /home/ec2-user/minecraft_server.jar https://minecraft.net/latest.jar"
}

2. Schedule Happy Hour Reminders in Slack 🍻

Using Ansible, you can automate sending Slack reminders every Friday at 4 PM.

1
2
3
4
5
6
7


- name: Happy Hour Reminder
 hosts: localhost
 tasks:
 - name: Send Slack Message
 community.general.slack:
 token: "{{ slack_token }}"
 msg: "It's Friday! Time for a beer 🍺"

3. Automate Cat Picture Delivery 🐱

You can use AWS Lambda and Terraform to set up a pipeline that fetches a random cat picture from an API and posts it to your Twitter every day. Because why not?

4. Turn Your Lights On/Off with Terraform 💡

Home automation? With Pulumi, you can control your smart home devices via AWS IoT. A single config change can turn your lights on and off.

5. Create a Server That Self-Destructs 💥

Want to deploy a self-destructing AWS EC2 instance? Just use an auto-terminating Terraform script that deletes itself after 10 minutes. Great for security testing!

6. Track Your Plant’s Watering Schedule 🌱

Using IoT + IaC, you can automate plant watering reminders or even integrate with a smart irrigation system.

7. Spin Up a Fake Company Website for Fun 🏢

Ever wanted to prank your coworkers? Use CloudFormation to deploy a static S3-hosted website for a fake company with official-looking branding.

8. Automate Your Resume Deployment 📄

Some developers host their resumes on AWS S3 and use IaC to update it dynamically when they make Git commits. Smart move for job seekers!

How I Took a Legacy App from Bare Metal to AWS

Wed, 05 Oct 2022 00:00:00 +0000

How I Took a Legacy App from Bare Metal to AWS

The Nightmare I Walked Into

I got hired as a software engineer at this job, with years of experience with AWS, Azure and Google Cloud..

WRITING CLOUD CODE.. not doing a ton of DevOps

In the interview they asked me “Hey, can you move our internal app to AWS?”.

I said yes, having no idea what kind of mess I was walking into.

Sure I ran old school websites (Early 2000’s) where we did crazy things to fix real time scaling business problem level issues…

The busiest site I worked on: I was Director of Engineering (and head coder ;) ) for a Meta\Dropbox Competitor.. Our Bandwidth bill was around $100K a month… lots of users for us at least…

So we made alot of mistakes.. learned alot of lessons .. and used alot of Duct tape to solve problems..

We moved MySql into a RAM drive to make it go faster.. To buy us time to clean up the sql code..
We did weird round robin tricks with client side code rotating app servers to try to scale..

Good painful learning experiences…..
And these hacks worked.. until the next probelm cropped up..

I didnt get much sleep in those days..

but that aside.. this new job was for a large 100,000 employee technolgy company …

And what the described in the interview didnt sound THAT bad… It just sounded like some old code and a slow computer..

Ill make a few code tweaks..

Its just some api changes right? Local files into S3.. Reinstall the SQL Server and data into a cloud managed system..

Fix it allup in an afternoon and be home for supper…
(yes us old poeple say “supper”…)

SURE I can do this.. no problem…

hahah

So they hired me…

Then i learned more about what I was dealing with …

This server was running on a single server in a Sacramento data center, complete with notepad instructions on the desktop for how the confiuration .. MIGHT be setup…..

The original dev had tried to “scale” it by adding IT provisioned Virtual MAchines as App servers.. ,
but the database and web server were running on the same ancient Celeron machine.

AND the App Server VMs, were MAKING CALLS BACK TO THE PHYSICAL SERVER FOR DATABASE ACCESS

Umm.. ok…

Exactly how is that a goood idea?

I am still not sure..

Maybe its like if you mixed Horizontal Scaling with Quantum Mechanics… ????

Oh, and international users were complaining because, surprise surprise, Sacramento is not great for global access.

Step 1: Cleaning Up the Code

The first issue? The codebase looked like it was written by someone in a hurry, in the dark, during an earthquake.

Weird things I found:

Hardcoded Configurations Everywhere

I found this:

1

string connectionString = "Server=localhost;Database=MyDB;User Id=admin;Password=SuperSecret";

Seriously?!

Fix: Move everything to environment variables -later- AWS Secrets Manager.

1

string connectionString = Environment.GetEnvironmentVariable("DB_CONNECTION_STRING");

Tightly Coupled Code

Everything was jammed into a single class. Changing anything broke everything.

Fix: Dependency injection.

1
2
3
4
5
6


public class ReportService {
 private readonly IDataRepository _repo;
 public ReportService(IDataRepository repo) {
 _repo = repo;
 }
}

Now I could actually test stuff without breaking the whole app.

Stateful Sessions

Session data was being stored on the web server. This was not gonna scale too well..

Fix: Move sessions to Redis.

1

_cache.Set("User", user, new MemoryCacheEntryOptions { SlidingExpiration = TimeSpan.FromMinutes(30) });

Now, users wouldn’t be tied to a single instance.

Step 2: Moving to AWS

Now that the app was less of a dumpster fire, it was time to migrate.

After that I HIT the Books with DevOps and AWS Scaling…..

Auto Scaling and Load Balancing

I set up an Elastic Load Balancer (ELB) and Auto Scaling Group (ASG) so AWS could spin up new instances as needed.

1
2
3
4
5
6


resource "aws_autoscaling_group" "my_app_asg" {
 launch_configuration = aws_launch_configuration.my_app_lc.id
 min_size = 2
 max_size = 10
 desired_capacity = 2
}

No more single-server nightmares.

CloudFront for Performance?

I tried adding CloudFront to cache static assets, but that didn’t work on our Corporate Intranet.
(Here is how you could do it if it can work for you.)

1
2
3
4
5
6


resource "aws_cloudfront_distribution" "my_app_cf" {
 origin {
 domain_name = aws_s3_bucket.my_app_static.bucket_regional_domain_name
 origin_id = "S3Origin"
 }
}

More on Cloudfront and why it doesnt play nicely with Intranets
https://stackoverflow.com/questions/70556875/how-to-use-cloudfront-only-on-the-internal-network

Moving the Database to AWS RDS

I moved the database off the web server and into AWS RDS (SQL Server), where it belonged.

1
2
3
4
5


resource "aws_db_instance" "my_app_db" {
 allocated_storage = 50
 engine = "sqlserver-se"
 instance_class = "db.t3.medium"
}

Now I had backups, failover, and no more single points of failure.

CI/CD with AWS CodePipeline

No more manual deployments! I set up AWS CodePipeline so everything deployed automatically.

1
2
3
4
5
6
7
8
9


stages:
 - name: Build
 actions:
 - name: BuildApp
 provider: CodeBuild
 - name: Deploy
 actions:
 - name: DeployToAWS
 provider: CodeDeploy

Migrating IIS and the Celeron Web Server

Now, the biggest challenge—moving the ASP.NET app running on IIS on that overworked Celeron machine.

Containerizing IIS

First, I put the IIS-based ASP.NET application into a Docker container to make deployment more consistent.

1
2
3


FROM mcr.microsoft.com/dotnet/framework/aspnet:4.8
WORKDIR /inetpub/wwwroot
COPY . .

This way, we could move it anywhere without worrying about system differences.

Running on AWS Elastic Beanstalk

To avoid the headache of managing IIS servers manually, I deployed the container to AWS Elastic Beanstalk, which handles scaling and updates automatically.

1
2
3
4
5


service: myapp
platform: Windows Server 2019 with IIS
option_settings:
 aws:elasticbeanstalk:container:dotnet:
 EnableApplicationHealthCheck: true

Now, AWS managed the underlying instances, and I didn’t have to worry about IIS configs.

Replacing IIS with AWS App Runner

For long-term stability, I moved the app to AWS App Runner, which allows running web applications without dealing with servers.

1
2
3
4
5
6
7


service:
 name: myapp-service
 instance_configuration:
 cpu: 2
 memory: 4GB
 deployment:
 image_uri: "<ECR_REPO_URI>:latest"

Now, the app was fully managed, auto-scaled, and not dependent on a single server anymore!

The Final Results

After months of refactoring, debugging, and questioning my life choices, the app was fully running in AWS:

It auto-scales when needed.
Users in India and North America both get fast response times.
No more single points of failure.

And most importantly—I finally started to understand Modern DevOps.

No more duct tape.. :)

Key Takeaways

Issue	Solution
Hardcoded Config Values	Used environment variables and Secrets Manager
Tightly Coupled Code	Introduced dependency injection
Stateful Sessions	Used Redis for distributed session storage
Single-Server Bottleneck	Implemented AWS Auto Scaling and Load Balancer
Global Performance Issues	Used Route 53 and CloudFront for faster access
Database on Web Server	Migrated to AWS RDS
Manual Deployments	Set up CI/CD with AWS CodePipeline

Reference Links

Move a legacy IIS app to the AWS Cloud

Sun, 14 Jan 2024 00:00:00 +0000

If you’re still running an IIS app on some forgotten rack server in a basement, it’s time to bring it into the 21st century.

Why Move IIS Apps to AWS?

Before we jump into how, let’s talk about why:

No more “server room” that doubles as a storage closet. AWS takes care of infrastructure.
Scalability. Your app can handle Black Friday traffic spikes without breaking a sweat.
Security. AWS is much better at security than “Steve from IT” who still uses “password123”.
Cost Savings. No more hardware replacements every few years.

Option 1: Elastic Beanstalk – The “I Want AWS to Do Everything for Me” Approach

Elastic Beanstalk is AWS’s Platform-as-a-Service (PaaS). It handles deployment, scaling, monitoring, and even updates. You just upload your app, sit back, and pretend you did something complex.

Steps to Deploy an IIS App with Beanstalk

Package your IIS app (as a ZIP file or Docker image).
Create an Elastic Beanstalk environment.
Deploy your app.

Here’s an example of deploying a Dockerized IIS app:

1
2
3


eb init -p docker my-iis-app
eb create my-iis-env
eb deploy

Pros:
✔️ AWS handles everything – networking, load balancing, autoscaling.
✔️ Supports multiple environments (dev, staging, production).

Cons:
❌ Less flexibility if you need custom configurations.
❌ May cost more if you don’t optimize properly.

Option 2: App Runner – The “I Just Want to Run My App” Approach

AWS App Runner is a fully managed service that lets you run containerized applications without dealing with infrastructure. Think of it like AWS’s version of Heroku.

Steps to Deploy with App Runner

Containerize your IIS app.
Push the image to Amazon Elastic Container Registry (ECR).
Create an App Runner service.

Example:

1
2


aws apprunner create-service --service-name my-iis-app \
 --source-configuration 'ImageRepositoryType=ECR,ImageIdentifier=123456789.dkr.ecr.us-east-1.amazonaws.com/my-iis-app:latest'

Pros:
✔️ Super simple setup.
✔️ Auto-scaling without complex configs.

Cons:
❌ Limited customization options.
❌ Only supports containerized apps.

Option 3: Docker on ECS – The “I Like Control (But Not Too Much)” Approach

If you want more control over how your app runs but don’t want to deal with servers, AWS Elastic Container Service (ECS) with Fargate is a great choice. It lets you run Docker containers without managing servers.

Steps to Deploy with ECS

Containerize your IIS app:

1
2


FROM mcr.microsoft.com/windows/servercore/iis
COPY ./my-app /inetpub/wwwroot

Push to ECR:

1
2
3


aws ecr create-repository --repository-name my-iis-app
docker tag my-iis-app:latest 123456789.dkr.ecr.us-east-1.amazonaws.com/my-iis-app:latest
docker push 123456789.dkr.ecr.us-east-1.amazonaws.com/my-iis-app:latest

Deploy with ECS Fargate:

1
2
3


aws ecs create-cluster --cluster-name my-iis-cluster
aws ecs create-service --cluster my-iis-cluster --service-name my-iis-app \
 --task-definition my-iis-task --launch-type FARGATE

Pros:
✔️ Full control over environment variables, networking, logging.
✔️ No need to manage VMs.

Cons:
❌ Slightly more complex than Beanstalk or App Runner.
❌ Requires more AWS knowledge.

Beanstalk vs. App Runner vs. ECS: Which One to Choose?

Feature	Elastic Beanstalk	App Runner	ECS (Fargate)
Ease of Use	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐
Flexibility	⭐⭐⭐	⭐⭐	⭐⭐⭐⭐⭐
Scaling	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐
Best For	Traditional apps	Simple containerized apps	High-control container apps

Final Thoughts

Moving an old IIS app to AWS isn’t as scary as it sounds.

Whether you choose Beanstalk, App Runner, or ECS, you’ll be saving yourself from a future of on-prem server nightmares.

Take that leap into the cloud, and maybe, just maybe, retire that ancient server that’s still running on Windows Server 2003.

Key Ideas

Concept	Summary
Elastic Beanstalk	Easiest way to deploy IIS apps with AWS managing everything
App Runner	Best for containerized apps with minimal setup
ECS Fargate	Best for full control over the deployment process

Reference Links

Azure DevOps-Continuous Integration & Continuous Deployment

Tue, 12 Sep 2023 00:00:00 +0000

Setting up CI/CD in Azure DevOps

“Why did the developer break up with Git?
Because it had too many commitment issues!”

Alright today we’re setting up CI/CD in Azure DevOps—because manually deploying code is so 2010, and we have better things to do (like debugging why our code doesn’t work in production).

This is basically the Azure DevOps version of this Jenkins CI/CD guide, but we’re replacing Jenkins with Azure Pipelines because… well, we like suffering slightly less.

What is CI/CD?

CI/CD is Continuous Integration and Continuous Deployment (or Delivery). It’s the magical process that ensures your code moves smoothly from your laptop (where it “works perfectly”) to production (where it immediately catches fire).

Continuous Integration (CI) → Developers push code changes frequently, and automation ensures everything is tested before merging.
Continuous Deployment (CD) → Once the code is tested, it’s automatically deployed, so you can focus on more important things, like why your API suddenly has a 500 error.

Setting Up Azure DevOps

First, you need an Azure DevOps account. If you don’t have one, go to Azure DevOps and sign up—it’s free for small teams, and Microsoft hasn’t yet figured out how to charge us for breathing.

Step 1: Create a New Project

In Azure DevOps, click New Project.
Give it a name, like "MyCoolProject" or "YetAnotherBuggyApp".
Choose Git for version control (because what else would you use, TFVC?!).

Setting Up the CI/CD Pipeline

Azure DevOps uses Azure Pipelines for CI/CD, which is basically Microsoft’s version of Jenkins but with more YAML and fewer plugins.

Step 2: Create a Build Pipeline

A build pipeline automates the compilation, testing, and artifact creation of your project.

Go to Pipelines > New Pipeline.
Choose GitHub (or Azure Repos Git if you’re fancy).
Select your repo and configure the pipeline using YAML (Yes, it’s YAML—brace yourself).

Example YAML for a .NET Project

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


trigger:
 - main

pool:
 vmImage: 'ubuntu-latest'

steps:
 - task: UseDotNet@2
 inputs:
 packageType: 'sdk'
 version: '7.x'

 - script: dotnet build --configuration Release
 displayName: 'Build Project'

 - script: dotnet test
 displayName: 'Run Tests'

 - task: PublishBuildArtifacts@1
 inputs:
 pathToPublish: 'bin/Release/net7.0'
 artifactName: 'drop'

This will:
✅ Run the build on Ubuntu (because we like free things).
✅ Install .NET SDK 7.x.
✅ Build the project.
✅ Run tests (so you can see them fail).
✅ Publish the artifacts for deployment.

Setting Up the Release Pipeline

The release pipeline deploys your app after a successful build.

Step 3: Create a Release Pipeline

Go to Releases > New Pipeline.
Use the Empty job template (because we’re starting fresh).
Add an Artifact source (pick the drop artifact from your build pipeline).

Step 4: Add Deployment Stage

Click Stage 1 and rename it to something like "Deploy to Staging" (or "Deploy and Pray").
Add a deployment task.
If deploying to Azure App Service, use the Azure App Service Deploy task.
Configure it with your Azure subscription, App Service name, and artifact location.

Example Deployment YAML

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


stages:
- stage: Deploy
 jobs:
 - job: DeployJob
 pool:
 vmImage: 'ubuntu-latest'
 steps:
 - task: AzureRmWebAppDeployment@4
 inputs:
 azureSubscription: 'MyAzureSubscription'
 appType: 'webApp'
 appName: 'my-cool-app'
 package: '$(Build.ArtifactStagingDirectory)/drop'

Adding a Deployment Trigger

Since we don’t want to manually trigger deployments like cavemen, let’s make it automatic:

Click on your release pipeline.
Add a trigger to deploy on successful builds.
Enable Continuous Deployment trigger.

Running the CI/CD Pipeline

Now, push a change to your main branch, sit back, and watch:

Build starts → Installs dependencies, compiles code, and runs tests.
Artifact is created → This is your deployable package.
Release starts → Deploys the artifact to your server.
Something breaks in production → You debug, cry, fix, repeat.

Summary of Key Ideas

CI/CD automates builds, testing, and deployments.
Azure DevOps Pipelines replaces Jenkins for CI/CD.
YAML-based Pipelines handle the entire process.
Deployment is automated so you can focus on more debugging.

References

Jenkins Setup-Continuous Integration and Deployment CICD

Sun, 05 Jan 2020 00:00:00 +0000

A Brief History of Jenkins

Jenkins, the beloved but sometimes infuriating CI/CD tool, was born out of necessity.

Back in 2004, Kohsuke Kawaguchi, a Sun Microsystems engineer, was tired of breaking builds and getting yelled at by his team.

So, like any good developer, he built a tool to automate the pain away.

This tool was originally called Hudson, but after some corporate drama with Oracle, it was forked and renamed Jenkins in 2011.

Since then, it has become the go-to tool for continuous integration and deployment.

(Fun note- Hudson was the version I learned initially :) - Yes.. I am old )

What is Continuous Integration and Continuous Deployment (CI/CD)?

Continuous Integration (CI) is like having a really strict but fair coding buddy who immediately runs tests whenever you push code.

If your code fails, it tells you instantly, saving you from merging a disaster into production.

Continuous Deployment (CD) takes it a step further and says, “Hey, your code passed?

Let’s deploy it to production automatically.” This ensures that software is always in a deployable state, with minimal human intervention.

In short: CI catches problems early, and CD ensures you’re always ready to ship.

Setting Up a Sample Microservice

Before Jenkins can do anything useful, we need something to build and test.

Let’s create a simple C# microservice that exposes a REST API to divide two numbers. If you try to divide by zero, it will yell at you—because math.

C# Microservice Code

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


using Microsoft.AspNetCore.Mvc;

[ApiController]
[Route("api/[controller]")]
public class MathController : ControllerBase
{
 [HttpGet("divide")]
 public IActionResult Divide(double a, double b)
 {
 if (b == 0)
 {
 return BadRequest("Division by zero is not allowed!");
 }
 return Ok(a / b);
 }
}

Unit Tests for the Microservice

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


using Xunit;
using Microsoft.AspNetCore.Mvc;

public class MathTests
{
 [Fact]
 public void Divide_ValidNumbers_ReturnsCorrectResult()
 {
 var controller = new MathController();
 var result = controller.Divide(10, 2) as OkObjectResult;

 Assert.NotNull(result);
 Assert.Equal(5.0, result.Value);
 }

 [Fact]
 public void Divide_ByZero_ReturnsBadRequest()
 {
 var controller = new MathController();
 var result = controller.Divide(10, 0) as BadRequestObjectResult;

 Assert.NotNull(result);
 Assert.Equal("Division by zero is not allowed!", result.Value);
 }
}

Running Unit Tests from the Command Line

1

dotnet test

If all goes well, you’ll see some green checkmarks. If not, well, time to debug.

Configuring Jenkins to Monitor Git and Build Code

Install Jenkins and necessary plugins (Git, Pipeline, Docker Pipeline).
Set up a new Freestyle Project or a Pipeline Project.
Link it to your Git repository.
Configure Jenkins to trigger a build when new code is pushed.

Example Jenkinsfile for CI/CD

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36


pipeline {
 agent any

 stages {
 stage('Clone Repository') {
 steps {
 git 'https://github.com/your-repo/math-service.git'
 }
 }

 stage('Build') {
 steps {
 sh 'dotnet build'
 }
 }

 stage('Test') {
 steps {
 sh 'dotnet test'
 }
 }

 stage('Dockerize and Deploy') {
 steps {
 sh 'docker build -t math-service .'
 sh 'docker run -d -p 5000:80 math-service'
 }
 }

 stage('Post-Deployment Test') {
 steps {
 sh './test-api.sh'
 }
 }
 }
}

What Happens if You Push Code Before the First Build Completes?

Chaos. Jenkins will either queue the new build or cancel the old one, depending on how it’s configured. Either way, you’ll probably get an email from your team.

Where Does Jenkins Put Built Files?

Jenkins stores built artifacts in /var/lib/jenkins/workspace/<job-name>/ by default. You can configure it to store them elsewhere.

Setting Up Failure Notifications

To notify a human when the build fails, configure Email Notifications or Slack Webhooks.

1
2
3
4
5
6
7


post {
 failure {
 mail to: 'devs@example.com',
 subject: 'Jenkins Build Failed',
 body: 'Check Jenkins, something broke.'
 }
}

Testing the API After Deployment

Create a simple test script:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


#!/bin/bash

response=$(curl -s -o /dev/null -w "%{http_code}" "http://localhost:5000/api/math/divide?a=10&b=2")

if [ "$response" -eq 200 ]; then
 echo "API test passed!"
else
 echo "API test failed!"
 exit 1
fi

Make it executable:

1

chmod +x test-api.sh

Deploying to Docker with Jenkins

Modify the Jenkins pipeline to build and run the Docker container, then execute test-api.sh.

1
2
3
4
5


stage('Post-Deployment Test') {
 steps {
 sh './test-api.sh'
 }
}

Cleaning Up After Docker Tests

1
2
3
4
5
6


stage('Cleanup') {
 steps {
 sh 'docker stop math-service'
 sh 'docker rm math-service'
 }
}

Retaining Files in Jenkins

Configure Build Artifacts in Jenkins to retain compiled files:

Keep artifacts for a certain number of builds.
Use “Discard old builds” to prevent disk bloat.

Competing CI/CD Tools

Jenkins isn’t the only player. Here are some alternatives:

GitHub Actions – Simple, integrated into GitHub.
GitLab CI/CD – Built-in CI for GitLab.
CircleCI – Cloud-based and fast.
Travis CI – Once great, now fading.
Azure DevOps – Microsoft’s answer to Jenkins.
TeamCity – Enterprise-grade CI/CD.

Azure LAN to Cloud Project- Part 1 - Project Vision and Goals

Tue, 03 Dec 2024 00:00:00 +0000

Welcome to the first installment of Azure LAN to Cloud, where we embark on an adventure to build a simple social media application for a local network (LAN) and then migrate it to Microsoft Azure’s cloud platform.

Why This Series?

Cloud migration isn’t just about taking your code and saying, “Hey, server! Meet Azure.”

No, no, no—it’s more like teaching a small-town LAN application to survive and thrive in the wild urban jungle of the cloud.

The goal of this series is to explore what it really takes to move from a cozy local network to the vast, sometimes overwhelming Azure cloud.

We’ll build an app that starts simple—a LAN-based social media chat application with image uploads and pushed chat updates—and then incrementally move it to Azure.

Along the way, we’ll learn about infrastructure as code, cloud security, authentication, Azure services like Functions, Redis, and blob storage, and much more.

The Local LAN Application

The application we start with will be deliberately simple but functional enough to mimic cloud features within a trusted LAN environment.

Here’s what it will have:

Multi-user chat: Real-time chat with pushed updates.
Image uploads: Share those cat memes with friends.
Multiple channels: Like Slack, but without the enterprise-grade seriousness.
Simple authentication: Just a name—no passwords, no email, no fuss.

The LAN app will assume a trusted environment—like your home network—so security will be minimal.

Users can choose any name, create any channel, and upload any image (yes, even that blurry vacation photo).

Tech Stack (Local Phase)

Python 3.11+ (because Python is awesome)
Flask or FastAPI (still deciding which mood we’re in)
SQLite (keeping it simple for the LAN phase)
WebSockets for real-time updates
Basic HTML/JS for the client

We’ll avoid fancy features that don’t add educational value and focus on building a functional app that mimics cloud patterns.

The Cloud Migration Challenge

Once the app is up and running locally, we’ll start the migration to Azure.

If you’re picturing a smooth and easy transition—well, surprise!

It won’t be.

And that’s by design.

Moving from LAN to cloud is a paradigm shift.

In the LAN version, we can just push updates to everyone, store images locally, and keep a list of active channels in memory.

But when we go cloud-side, these shortcuts become liabilities.

Cloud Migration Goals

Real Authentication: Goodbye “What’s your name?” Hello OAuth 2.0.
Scalable Image Handling: Blob storage, CDNs, and Azure Functions.
Distributed State: Redis for chat state.
Infrastructure as Code: Azure Resource Manager (ARM) templates, Bicep, or Terraform.
Horizontal Scalability: Containers, Kubernetes, and Azure Functions.

Expected Headaches (a.k.a. Learning Opportunities)

Migrating from SQLite to Azure SQL or CosmosDB.
Debugging performance bottlenecks in the cloud.
Implementing real-time chat across multiple nodes.
Cost optimization because, well, cloud bills.

The Plan (or, How We’ll Try to Stay Organized)

The journey will unfold in phases:

Phase 1: Local LAN App

Build a basic Python chat app with image uploads.
Test and document the core features.
Explore basic architecture patterns that mimic cloud behavior.

Phase 2: Initial Cloud Migration

Deploy the app on Azure App Service.
Migrate data to Azure SQL/Blob Storage.
Add basic authentication.

Phase 3: Cloud Optimization

Introduce Redis for state management.
Scale horizontally with containers.
Implement caching and performance tuning.

Phase 4: Production Readiness

Set up Azure DevOps pipelines.
Use Infrastructure as Code to manage deployments.
Add monitoring and logging.
Follow Modern Security Practices
- OWAS Tools In a Nutshell
- NIST Resources for Cloud Devs
Integrate OWASP Tools into our pipeline
- OWASP tools Integration into the DevOps pipeline

Phase 5: Mobile & Cross-Cloud Exploration

Add a MAUI-based mobile app.
Compare Azure with AWS and Google Cloud.

Why Azure?

I’ve been working with AWS and Azure since around 2008—back when Azure was simpler and cloud jargon didn’t require a dictionary.

Azure, like AWS, has grown immensely, and with growth comes complexity.

This series will give us a chance to explore Azure’s features without getting lost in the complexity jungle.

What’s Next?

In the next article, we’ll start building our LAN-based social media app.

Expect some Python code, some architectural diagrams, and maybe a cat meme or two.

Stay tuned, and remember: The cloud isn’t scary—it’s just someone else’s computer.

Key Ideas

Build a LAN-based social media app with chat, images, and channels.
Explore Azure services through a real migration process.
Focus on practical, hands-on learning with a working app.
Cover DevOps, Infrastructure as Code, and performance optimization.

References

Microsoft Azure Documentation: https://docs.microsoft.com/azure
Python 3.11+ Official Documentation: https://docs.python.org/3.11/
Flask Web Framework: https://flask.palletsprojects.com/
FastAPI Documentation: https://fastapi.tiangolo.com/
Redis Documentation: https://redis.io/documentation
Docker Documentation: https://docs.docker.com/
Azure Functions: https://docs.microsoft.com/azure/azure-functions
MAUI Documentation: https://learn.microsoft.com/en-us/dotnet/maui/
OAuth 2.0 Framework: https://oauth.net/2/
Infrastructure as Code: https://docs.microsoft.com/azure/azure-resource-manager/templates/overview

How Bamboo and Octopus Work Together

Mon, 30 Nov 2020 00:00:00 +0000

The History of Each Tool

Bitbucket 🏗️ – Git Repo Hosting by Atlassian

Once upon a time (2008, to be exact), Bitbucket was born as a Mercurial-based repository hosting service.

But, since nobody outside of a few stubborn devs really cared about Mercurial, Atlassian acquired it in 2010 and gave it a Git makeover. Now, it’s one of the big Git repo hosting services, standing alongside GitHub and GitLab.

👉 Think of Bitbucket as: The cool storage locker where all your code lives before it gets deployed.

More on Bitbucket: https://bitbucket.org/

Bamboo 🎋 – CI/CD for the Atlassian World

Atlassian created Bamboo as an alternative to Jenkins because, let’s be honest, Jenkins is great but looks like it belongs in Windows 95.

Bamboo was built to integrate smoothly with Bitbucket, Jira, and other Atlassian tools. It provides CI/CD pipelines with a slick UI and deep integrations with source control.

👉 Think of Bamboo as: The conveyor belt in your software factory, making sure your code gets tested and built correctly before it ships.

More on Bamboo: https://www.atlassian.com/software/bamboo

Octopus Deploy 🐙 – The Deployment Powerhouse

Founded in 2012, Octopus Deploy is an independent deployment automation tool. While Bitbucket and Bamboo handle the coding and building,

Octopus takes care of the actual deployment. It specializes in multi-environment releases (like Dev, Staging, Production) and supports auto-rollback, variable scoping, and approvals.

👉 Think of Octopus as: The expert delivery guy making sure your software package is delivered safely—whether to Kubernetes, AWS, or a bunch of VMs.

More on Octopus Deploy: https://octopus.com/

How They Work Together

Here’s a high-level overview of how Bitbucket, Bamboo, and Octopus collaborate in a CI/CD pipeline:

Bitbucket – Developers push their code to a Bitbucket repository.
Bamboo – Detects the new code, runs automated tests, and builds the application.
Octopus Deploy – Takes the successfully built artifact and deploys it to environments like Staging or Production.

CI/CD Example: Bitbucket + Bamboo + Octopus

1. Bitbucket Pipelines (Optional)

If you’re not using Bamboo yet, you can have Bitbucket Pipelines handle initial builds.

1
2
3
4
5
6
7
8


image: mcr.microsoft.com/dotnet/sdk:6.0

pipelines:
 default:
 - step:
 script:
 - dotnet build
 - dotnet test

2. Bamboo Build Plan

In Bamboo:

Create a new plan and connect it to your Bitbucket repo.
Add a build step:
- Use a Docker container or build script.
- Run tests and package the app.
Artifact Sharing – Save the build output so Octopus Deploy can use it.

3. Octopus Deploy Process

Define Environments (e.g., Dev, Staging, Prod).
Create a Release Pipeline:
- Pulls build artifacts from Bamboo.
- Deploys to Kubernetes, AWS ECS, Azure, or on-prem servers.
Set up Approval Steps if needed.

Key Ideas Table

Step	Description
Bitbucket	Git-based repo hosting from Atlassian
Bamboo	CI/CD automation and build pipelines
Octopus Deploy	Deployment automation and release management
Integration	Bitbucket triggers Bamboo; Bamboo builds and sends artifacts to Octopus Deploy
Example Code	Bitbucket Pipelines YAML, Bamboo Build Plan, Octopus Deployment

Reference Links

Final Thoughts

Bitbucket, Bamboo, and Octopus work best together like peanut butter, jelly, and bread. Bitbucket stores your code, Bamboo makes sure it actually works, and Octopus gets it where it needs to go. If you’re looking for a solid, battle-tested CI/CD setup, this trio is a fantastic choice.

Now go forth and automate your deployments like a DevOps wizard! 🧙‍♂️✨

Ansible in a nutshell

Mon, 11 Nov 2019 00:00:00 +0000

Ansible in a Nutshell

What is Ansible?

Ansible is like a magic wand for system administrators.

You write some YAML, wave your SSH key, and boom!

Servers are configured, applications are deployed, and your DevOps team thinks you’re a genius (until they see your YAML indentation errors). (hahaha)

A Brief History of Ansible (Or How We Got Here)

Ansible was created in 2012 by Michael DeHaan, who must have been tired of writing the same Bash scripts over and over.

Instead of spending hours debugging shell scripts, he decided to make a tool that could automate infrastructure easily, with no agents or extra dependencies. Thus, Ansible was born!

(Software engineers had tedious things - so we invent things.. sometimes people use our things and think our things are too tedious… so they invent more things.. the world is full of things… and this is why….)

In 2015, Red Hat acquired Ansible, proving that if you make a good enough open-source tool, eventually someone will throw money at you.

Infrastructure as Code (IaC) - The Big Picture

If you’ve ever heard the phrase “treat your servers like cattle, not pets,” then you already get the gist of Infrastructure as Code. Instead of manually configuring each server like a delicate bonsai tree, IaC lets you define everything in code so that it can be automated, version-controlled, and replicated.

Ansible takes this a step further by making sure you don’t need a Ph.D. in YAML just to get things working (though it helps).

How Does Ansible Compare to Other Tools?

🏆 Ansible vs. Puppet

Ansible: Agentless, uses SSH, simple to set up.
Puppet: Uses agents, requires a master node, more complex but powerful.

🏆 Ansible vs. Chef

Ansible: Uses YAML (easy to read, but can be annoying to debug).
Chef: Uses Ruby (which means, if you’re not a Ruby dev, good luck).

🏆 Ansible vs. Terraform

Ansible: Great for configuration management and app deployment.
Terraform: Great for infrastructure provisioning (they actually work well together!).

Common Ansible Examples

1. Installing Packages

1
2
3
4
5
6
7


- name: Install Nginx
 hosts: web_servers
 tasks:
 - name: Install Nginx
 apt:
 name: nginx
 state: present

2. Starting a Service

1
2
3
4
5
6
7
8


- name: Start and Enable Nginx
 hosts: web_servers
 tasks:
 - name: Start Nginx
 service:
 name: nginx
 state: started
 enabled: yes

3. Copying a File

1
2
3
4
5
6
7


- name: Copy Config File
 hosts: all
 tasks:
 - name: Copy nginx.conf
 copy:
 src: ./nginx.conf
 dest: /etc/nginx/nginx.conf

4. Running a Shell Command

1
2
3
4
5


- name: Check Disk Usage
 hosts: all
 tasks:
 - name: Run df command
 command: df -h

5. Creating a User

1
2
3
4
5
6
7


- name: Create a User
 hosts: all
 tasks:
 - name: Add User
 user:
 name: devops
 state: present

6. Deploying an App

1
2
3
4
5
6
7


- name: Deploy Web App
 hosts: web_servers
 tasks:
 - name: Pull latest code
 git:
 repo: 'https://github.com/example/repo.git'
 dest: /var/www/html

7. Managing Firewall Rules

1
2
3
4
5
6
7
8


- name: Open Port 80
 hosts: all
 tasks:
 - name: Allow HTTP traffic
 ufw:
 rule: allow
 port: 80
 proto: tcp

8. Configuring a Database

1
2
3
4
5
6
7


- name: Configure MySQL
 hosts: db_servers
 tasks:
 - name: Ensure MySQL is installed
 apt:
 name: mysql-server
 state: present

9. Using Variables

1
2
3
4
5
6
7
8
9


- name: Install Custom Package
 hosts: all
 vars:
 package_name: htop
 tasks:
 - name: Install package
 apt:
 name: "{{ package_name }}"
 state: present

10. Looping Over Tasks

1
2
3
4
5
6
7


- name: Install Multiple Packages
 hosts: all
 tasks:
 - name: Install common tools
 apt:
 name: [vim, curl, git]
 state: present

Key Ideas

Topic	Summary
What is Ansible?	A simple, agentless automation tool using YAML.
History	Created in 2012, acquired by Red Hat in 2015.
Infrastructure as Code	Managing servers using code instead of manual setup.
Comparison	Competes with Puppet, Chef, Terraform (but works well with Terraform).
Common Usage	Configuration management, deployment, provisioning.

Reference Links

Terraform in a Nutshell

Tue, 14 Sep 2021 00:00:00 +0000

Terraform in a Nutshell

Introduction

Terraform: the Swiss Army knife of Infrastructure as Code (IaC). If you’ve ever wanted to manage cloud infrastructure like a boss without manually clicking through AWS, Terraform is your new best friend.

It automates the entire process, leaving you more time to drink coffee and pretend you’re fixing production issues. ☕🔥

A Brief History of Terraform

Back in the day (pre-2014), cloud provisioning was a wild, wild west of manual configurations and spaghetti scripts.

Then, HashiCorp entered the scene with Terraform, a tool that changed everything by introducing declarative infrastructure as code. Instead of imperative scripts (do X, then Y), Terraform lets you define the desired end state, and it figures out the rest.

Since then, it’s become the de facto standard for managing cloud infrastructure, outshining other tools like AWS CloudFormation and Ansible for provisioning tasks.

Why is Terraform so popular?
✅ Multi-cloud support – Works with AWS, Azure, GCP, Kubernetes, and even random things like Cloudflare DNS.
✅ State management – Keeps track of infrastructure changes with a state file.
✅ Modular – You can reuse Terraform code across projects.
✅ Easy to learn – HCL (HashiCorp Configuration Language) is simpler than YAML, JSON, or writing Bash scripts at 3 AM.

Terraform vs. Other IaC Tools

Feature	Terraform	CloudFormation	Pulumi	Ansible
Multi-cloud	✅ Yes	❌ AWS-only	✅ Yes	✅ Yes
Declarative	✅ Yes	✅ Yes	❌ No (Imperative)	❌ No (Imperative)
State Management	✅ Yes	✅ Yes	❌ No	❌ No
Programming Language	HCL	YAML/JSON	Python/JS/Go	YAML
Best For	Cloud provisioning	AWS environments	Devs who like real languages	Configuration management

If you want to provision multi-cloud infrastructure, use Terraform. If you’re AWS-only, CloudFormation is fine. If you prefer Python, try Pulumi. If you just want to install packages, use Ansible.

10 Common Terraform Code Examples

1. Provision an AWS EC2 Instance

1
2
3
4
5
6
7


provider "aws" {
 region = "us-east-1"
}
resource "aws_instance" "my_vm" {
 ami = "ami-12345678"
 instance_type = "t2.micro"
}

2. Create an S3 Bucket

1
2
3
4


resource "aws_s3_bucket" "my_bucket" {
 bucket = "my-awesome-bucket"
 acl = "private"
}

3. Deploy a Load Balancer

1
2
3
4
5


resource "aws_lb" "my_lb" {
 name = "my-load-balancer"
 internal = false
 load_balancer_type = "application"
}

4. Spin Up an RDS Database

1
2
3
4
5


resource "aws_db_instance" "my_db" {
 engine = "postgres"
 instance_class = "db.t3.micro"
 allocated_storage = 20
}

5. Provision a Kubernetes Cluster (EKS)

1
2
3
4


resource "aws_eks_cluster" "my_eks" {
 name = "my-cluster"
 role_arn = aws_iam_role.eks_role.arn
}

6. Manage DNS Records with Cloudflare

1
2
3
4
5
6


resource "cloudflare_record" "my_dns" {
 zone_id = "your-zone-id"
 name = "example.com"
 type = "A"
 value = "192.168.1.1"
}

7. Create a Terraform Module

1
2
3
4


module "s3_bucket" {
 source = "terraform-aws-modules/s3-bucket/aws"
 bucket = "my-modular-bucket"
}

8. Use Terraform Variables

1
2
3
4
5
6


variable "instance_type" {
 default = "t2.micro"
}
resource "aws_instance" "my_vm" {
 instance_type = var.instance_type
}

9. Set Up Auto Scaling

1
2
3
4
5


resource "aws_autoscaling_group" "my_asg" {
 desired_capacity = 2
 min_size = 1
 max_size = 5
}

10. Use Terraform Outputs

1
2
3


output "instance_ip" {
 value = aws_instance.my_vm.public_ip
}

Key Ideas Table

Concept	Explanation
Terraform	Open-source IaC tool by HashiCorp
Multi-cloud support	Works with AWS, Azure, GCP, Kubernetes, and more
State Management	Keeps track of infrastructure changes
HCL	HashiCorp’s configuration language for Terraform
Comparison	Competes with CloudFormation, Pulumi, and Ansible
Example Uses	Provisioning VMs, Load Balancers, Kubernetes, and DNS

Reference Links

Azure Data Storage Compared Blob, File, Table, Cosmos DB, SQL

Tue, 05 Dec 2023 00:00:00 +0000

So, you’re diving into Azure and wondering, “What’s the best way to store my precious data?”

Why Azure for Data Storage?

Azure is like that fancy buffet with all-you-can-eat options for data storage. Whether you’re dealing with images, logs, documents, or structured data, Azure’s got you covered.

Here’s the menu:

Blob Storage: For unstructured data like files, images, and videos.
File Storage: For network file shares.
Table Storage: For NoSQL key-value stores.
Cosmos DB: For scalable NoSQL databases.
SQL Database: For relational data.

Let’s dig into each of these with code samples in Python and C#.

1. Azure Blob Storage: When You Just Need a Bucket of Files 🪣

Blob Storage is perfect for when you need a place to dump files—think of it like a cloud-based USB drive.

Python Code 🐍

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


from azure.storage.blob import BlobServiceClient

connection_string = "<YourConnectionString>"
container_name = "my-container"
blob_name = "hello.txt"

# Initialize client
client = BlobServiceClient.from_connection_string(connection_string)
container_client = client.get_container_client(container_name)

# Upload blob
with open("hello.txt", "rb") as data:
 container_client.upload_blob(name=blob_name, data=data)

print("Blob uploaded successfully!")

C# Code ⚙️

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


using Azure.Storage.Blobs;
using System;
using System.IO;

string connectionString = "<YourConnectionString>";
string containerName = "my-container";
string blobName = "hello.txt";

BlobServiceClient blobServiceClient = new BlobServiceClient(connectionString);
BlobContainerClient containerClient = blobServiceClient.GetBlobContainerClient(containerName);

using FileStream fs = File.OpenRead("hello.txt");
containerClient.UploadBlob(blobName, fs);

Console.WriteLine("Blob uploaded successfully!");

Blob Storage Verdict:

Great for unstructured data.
Easily scalable.
Not ideal if you need querying or indexing.

2. Azure File Storage: Your Cloud-Based Shared Drive 📂

Think of Azure File Storage as your network drive in the sky.

Python Code 🐍

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


from azure.storage.fileshare import ShareFileClient

connection_string = "<YourConnectionString>"
share_name = "my-share"
file_name = "notes.txt"

file_client = ShareFileClient.from_connection_string(connection_string, share_name, file_name)

with open("notes.txt", "rb") as data:
 file_client.upload_file(data)

print("File uploaded successfully!")

C# Code ⚙️

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


using Azure.Storage.Files.Shares;
using System;
using System.IO;

string connectionString = "<YourConnectionString>";
string shareName = "my-share";
string fileName = "notes.txt";

ShareFileClient fileClient = new ShareFileClient(connectionString, shareName, fileName);

using FileStream fs = File.OpenRead("notes.txt");
fileClient.Upload(fs);

Console.WriteLine("File uploaded successfully!");

File Storage Verdict:

Perfect for shared file access.
SMB protocol support.
Not designed for large-scale analytics workloads.

3. Azure Table Storage: The NoSQL Key-Value Whisperer 🔑

Azure Table Storage offers a super-simple NoSQL solution for key-value data.

Python Code 🐍

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


from azure.data.tables import TableServiceClient, TableEntity

connection_string = "<YourConnectionString>"
table_name = "mytable"

# Create table client
table_service = TableServiceClient.from_connection_string(connection_string)
table_client = table_service.get_table_client(table_name)

# Insert entity
table_client.create_entity(entity={
 "PartitionKey": "users",
 "RowKey": "1",
 "Name": "Alice",
 "Age": 30
})

print("Entity inserted successfully!")

C# Code ⚙️

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


using Azure.Data.Tables;
using System;

string connectionString = "<YourConnectionString>";
string tableName = "mytable";

TableClient tableClient = new TableClient(connectionString, tableName);

var entity = new TableEntity("users", "1")
{
 { "Name", "Alice" },
 { "Age", 30 }
};

tableClient.AddEntity(entity);

Console.WriteLine("Entity inserted successfully!");

Table Storage Verdict:

Simple and fast for key-value data.
Great for logs and telemetry.
Limited querying capabilities.

4. Azure Cosmos DB: The Swiss Army Knife of NoSQL 🌌

Cosmos DB supports multiple NoSQL models with global distribution.

Python Code 🐍

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


from azure.cosmos import CosmosClient

url = "<YourCosmosDBUrl>"
key = "<YourKey>"
database_name = "mydb"
container_name = "mycontainer"

client = CosmosClient(url, key)
database = client.create_database_if_not_exists(id=database_name)
container = database.create_container_if_not_exists(id=container_name, partition_key=PartitionKey(path="/id"))

item = {"id": "1", "name": "Alice", "age": 30}
container.create_item(item)

print("Item inserted successfully!")

C# Code ⚙️

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


using Microsoft.Azure.Cosmos;
using System;
using System.Threading.Tasks;

string endpointUrl = "<YourCosmosDBUrl>";
string primaryKey = "<YourKey>";
string databaseName = "mydb";
string containerName = "mycontainer";

CosmosClient cosmosClient = new CosmosClient(endpointUrl, primaryKey);
Database database = await cosmosClient.CreateDatabaseIfNotExistsAsync(databaseName);
Container container = await database.CreateContainerIfNotExistsAsync(containerName, "/id");

var item = new { id = "1", name = "Alice", age = 30 };
await container.CreateItemAsync(item, new PartitionKey(item.id));

Console.WriteLine("Item inserted successfully!");

Cosmos DB Verdict:

Supports various NoSQL models.
Global distribution built-in.
Pricier than Table Storage.

5. Azure SQL Database: Old-School Relational Goodness 📊

When you need the comfort of good ol’ SQL.

Python Code 🐍

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


import pyodbc

server = "<YourServer>"
database = "mydb"
username = "<YourUsername>"
password = "<YourPassword>"

conn_str = f"DRIVER={{ODBC Driver 17 for SQL Server}};SERVER={server};DATABASE={database};UID={username};PWD={password}"

with pyodbc.connect(conn_str) as conn:
 cursor = conn.cursor()
 cursor.execute("CREATE TABLE IF NOT EXISTS Users (Id INT, Name NVARCHAR(50))")
 cursor.execute("INSERT INTO Users (Id, Name) VALUES (?, ?)", 1, "Alice")
 conn.commit()

print("SQL data inserted successfully!")

C# Code ⚙️

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


using System;
using System.Data.SqlClient;

string connectionString = "Server=<YourServer>;Database=mydb;User Id=<YourUsername>;Password=<YourPassword>;";

using SqlConnection connection = new SqlConnection(connectionString);
connection.Open();

string createTableQuery = "CREATE TABLE IF NOT EXISTS Users (Id INT, Name NVARCHAR(50))";
string insertQuery = "INSERT INTO Users (Id, Name) VALUES (1, 'Alice')";

using SqlCommand cmd = new SqlCommand(createTableQuery, connection);
cmd.ExecuteNonQuery();

cmd.CommandText = insertQuery;
cmd.ExecuteNonQuery();

Console.WriteLine("SQL data inserted successfully!");

SQL Database Verdict:

The classic choice for relational data.
Azure manages scaling, backups, and security.
Requires schema design upfront.

Key Ideas

Azure offers various storage options for different needs.
Python and C# both have robust libraries for interacting with Azure.
Blobs are great for files; tables are great for logs; Cosmos DB is fantastic for global apps.
Choose based on your workload and data requirements.

References

Azure- Tracing, Debugging, Troubleshooting, and Monitoring

Mon, 05 Dec 2022 00:00:00 +0000

1. Tracing: Follow the Breadcrumbs

Tracing is like leaving sticky notes throughout your codebase saying, “Hey, I was here, and I did this thing.” It’s essential for understanding application flow and performance.

Azure Tools for Tracing

Azure Monitor: Collects logs, metrics, and traces.
Application Insights: Great for distributed tracing.
Log Analytics: Query logs like a pro.

Best Practices for Tracing

Use correlation IDs across services.
Don’t log sensitive info. Nobody wants passwords exposed.
Use structured logging (e.g., JSON) for better parsing.

Tracing in C#

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


using Microsoft.Extensions.Logging;

public class MyService
{
 private readonly ILogger<MyService> _logger;

 public MyService(ILogger<MyService> logger)
 {
 _logger = logger;
 }

 public void ProcessData()
 {
 _logger.LogTrace("Starting data processing");
 // Do some work
 _logger.LogTrace("Finished data processing");
 }
}

Tracing in Python

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


import logging

logging.basicConfig(level=logging.DEBUG)
logger = logging.getLogger(__name__)

def process_data():
 logger.debug("Starting data processing")
 # Do some work
 logger.debug("Finished data processing")

process_data()

What Works:

Azure Application Insights makes distributed tracing simple.
Structured logs are easy to search.

What Doesn’t:

Over-logging can cause performance hits.
Ignoring trace correlation in microservices makes debugging a nightmare.

2. Debugging: The Code Detective

Debugging is the art of staring at code until you find the bug… or the bug finds you.

Azure Debugging Tools

Azure App Service Diagnostics: Interactive troubleshooting for web apps.
Azure DevOps: Integrated with Visual Studio.
Live Debugging with Azure Monitor: Debug apps without redeploying.

Best Practices

Reproduce issues locally whenever possible.
Use remote debugging sparingly in production.
Leverage exception tracking.

Debugging in C#

1
2
3
4
5
6
7
8
9


try
{
 int result = 10 / int.Parse("0");
}
catch (Exception ex)
{
 Console.WriteLine($"Exception caught: {ex.Message}");
 // Add breakpoint here
}

Debugging in Python

1
2
3
4
5


try:
 result = 10 / 0
except Exception as e:
 print(f"Exception caught: {e}")
 # Add a breakpoint here

What Works:

Visual Studio’s remote debugging is fantastic.
Python’s pdb debugger is simple yet powerful.

What Doesn’t:

Remote debugging production apps can degrade performance.
Debugging containerized apps can be tricky if logging isn’t set up properly.

3. Troubleshooting: Diagnosing the Mystery

Troubleshooting is about going full-on CSI: Cloud Edition. It involves analyzing patterns, logs, metrics, and errors.

Azure Troubleshooting Tools

Azure Service Health: Check Azure service status.
Azure Resource Health: Resource-specific diagnostics.
Kusto Query Language (KQL): Query logs easily.

Best Practices

Automate alerts for key metrics.
Use KQL for pattern detection.
Document common issues and their resolutions.

Troubleshooting in C#

1
2
3
4


using Microsoft.ApplicationInsights;

var telemetryClient = new TelemetryClient();
telemetryClient.TrackException(new Exception("Test exception"));

Troubleshooting in Python

1
2
3
4


from applicationinsights import TelemetryClient

client = TelemetryClient('your_instrumentation_key')
client.track_exception()

What Works:

Automated alerts with Application Insights.
KQL is incredibly powerful for investigating issues.

What Doesn’t:

Relying on manual log checks is exhausting.

4. Monitoring: Watch It Like a Hawk

Monitoring is like being a helicopter parent, but for your application.

Azure Monitoring Tools

Azure Monitor: Centralized metrics and logs.
Azure Application Insights: App performance insights.
Azure Log Analytics: Query logs with KQL.

Best Practices

Use dashboards to visualize metrics.
Set up anomaly detection.
Monitor performance, not just failures.

Monitoring in C#

1
2


var telemetryClient = new TelemetryClient();
telemetryClient.TrackMetric("ResponseTime", 200);

Monitoring in Python

1
2
3
4


from applicationinsights import TelemetryClient

client = TelemetryClient('your_instrumentation_key')
client.track_metric('ResponseTime', 200)

What Works:

Application Insights with live metrics.
Automated anomaly detection reduces manual overhead.

What Doesn’t:

Setting up too many alerts leads to alert fatigue.

Thoughts…

Tracing, debugging, troubleshooting, and monitoring your Azure application isn’t rocket science… but it does feel like juggling flaming swords sometimes.

The key is to implement structured logs, use the right tools, automate what you can, and stay cool when things break.

Key Ideas

Tracing: Follow app execution with logs.
Debugging: Investigate bugs via breakpoints and logs.
Troubleshooting: Diagnose issues using Azure tools.
Monitoring: Proactively watch application health.

References

Scale Deployments Horizontally in AWS-Iac

Tue, 15 Jun 2021 00:00:00 +0000

A Brief History of Infrastructure as Code

The Dark Ages (Pre-IaC Era)

Back in the ancient times (aka before IaC), developers and sysadmins had to manually configure servers, databases, and networking. This usually involved:

Clicking around in AWS like it’s a game of Minesweeper.
Copy-pasting long bash scripts that broke when your colleague looked at them wrong.
Manually provisioning infrastructure and forgetting how you did it when things went down.

In short: it was chaotic, error-prone, and not scalable. 😵

The Rise of IaC (2010s - Present)

Then came the heroes of Infrastructure as Code:

AWS CloudFormation (2011): AWS’s first attempt at automation using JSON/YAML.
Terraform (2014): HashiCorp introduced Terraform, bringing a multi-cloud, declarative IaC approach.
Pulumi, Ansible, and CDK: The IaC family expanded with more flexible tools.

Now, DevOps engineers could manage infrastructure the same way developers manage code—with version control, repeatability, and automation. 🎉

What is Infrastructure as Code? 🤔

Infrastructure as Code (IaC) is the practice of defining and managing cloud infrastructure using configuration files instead of manually setting things up.

Key benefits:

✅ Automation: No more clicking through AWS Console like a lost tourist.

✅ Version Control: Infrastructure changes are tracked in Git—no more “it worked on my machine” excuses.

✅ Repeatability: Deploy the same stack across different environments effortlessly.

✅ Scalability: Spin up 100 servers with a single command (or by accident—oops 🤭).

IaC is typically declarative (you define the desired state, and the tool figures out how to get there). The most popular tools include:

Terraform 🏗️ (multi-cloud, declarative HCL)
AWS CloudFormation ☁️ (AWS-only, YAML/JSON)
Pulumi (uses real programming languages)
Ansible (great for server configuration)

How to Deploy Applications in AWS Using IaC

Now that we understand IaC, let’s get our hands dirty with some examples. 🛠️

1. Deploying an EC2 Instance with Terraform

Terraform is an awesome IaC tool that lets you manage AWS, Azure, GCP, and more with a single config file.

📜 Terraform example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


provider "aws" {
 region = "us-east-1"
}

resource "aws_instance" "my_server" {
 ami = "ami-12345678"
 instance_type = "t2.micro"

 tags = {
 Name = "MyTerraformInstance"
 }
}

Run it:

1
2


terraform init
terraform apply

Your EC2 instance is now automated and repeatable. 🚀

!!!!
Cool eh?

2. Deploying an S3 Bucket with AWS CloudFormation

AWS CloudFormation lets you define AWS infrastructure using YAML or JSON.

📜 CloudFormation template:

1
2
3
4
5
6


AWSTemplateFormatVersion: '2010-09-09'
Resources:
 MyS3Bucket:
 Type: "AWS::S3::Bucket"
 Properties:
 BucketName: "my-cloudformation-bucket"

Deploy it:

1

aws cloudformation deploy --template-file template.yaml --stack-name MyS3Stack

You now have an S3 bucket without touching the AWS console. 🎉

!!!!!!
very cool…
!!!!!!

How to Scale Deployments Horizontally in AWS

Scaling horizontally means adding more instances rather than making a single instance more powerful. This is crucial for handling increased loads efficiently.

Using Auto Scaling Groups and Load Balancers

AWS provides Auto Scaling Groups (ASG) and Elastic Load Balancers (ELB) to distribute traffic and automatically add/remove instances based on demand.

📜 Terraform Example for Auto Scaling:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


resource "aws_launch_configuration" "my_app" {
 name = "my-app-config"
 image_id = "ami-12345678"
 instance_type = "t2.micro"
}

resource "aws_autoscaling_group" "my_asg" {
 launch_configuration = aws_launch_configuration.my_app.id
 min_size = 2
 max_size = 10
 desired_capacity = 3
 vpc_zone_identifier = ["subnet-abc123"]
}

This setup ensures more instances are added automatically when needed and removed when traffic decreases. 🚀

Pros and Cons of NOT Using IaC

The Nightmare of Manual Deployment

Without IaC	With IaC
Manually provisioning servers ☠️	Automate everything with scripts 🎉
Hard to replicate environments	Deploy the same infra repeatedly
Prone to human errors	Version-controlled infrastructure
Scaling means manually launching new instances	Auto Scaling ensures dynamic scaling
Debugging is painful	Logs and state management make troubleshooting easy

If you don’t use IaC, scaling becomes a tedious, manual nightmare. Imagine adding 50 EC2 instances manually while your website crashes—yeah, no thanks. 😅

Key Ideas Table

Concept	Explanation
Infrastructure as Code	Managing infrastructure with configuration files instead of manual processes.
Terraform	A multi-cloud declarative IaC tool using HCL.
AWS CloudFormation	AWS-native IaC tool using YAML/JSON.
Benefits of IaC	Automation, repeatability, scalability, and version control.
Horizontal Scaling	Adding more instances dynamically using Auto Scaling Groups.
Example Deployments	Terraform for EC2, CloudFormation for S3, ASG setup for scaling.
Cons of No IaC	Manual errors, lack of version control, slow scaling, and chaos.

Reference Links

Octopus in a nutshell

Sun, 27 Jan 2019 00:00:00 +0000

Octopus in a nutshell

A Brief History of Octopus

Back in 2011, a developer named Paul Stovell got fed up with the nightmare of deploying applications manually.

He figured, “Hey, why not make a tool that automates this mess?” And thus, Octopus Deploy was born.

Motivation: Why Octopus?

Before Octopus, deployment felt like:

SSHing into servers and praying nothing breaks
Copy-pasting config files like a caveman
Manually running SQL scripts and hoping they don’t nuke the database

Octopus Deploy came along and said, “Enough!” It introduced a smarter way:

✅ Automated deployments – No more 3 AM deployment calls!
✅ Rollback support – Because mistakes happen.
✅ Multi-environment support – Dev, Test, Prod? All handled!
✅ Permissions & security – Stop giving your intern access to production.
✅ Integration with everything – Azure, AWS, Kubernetes, and more.

Octopus vs. The Competition

So how does it stack up against the big names like Jenkins, GitHub Actions, and Azure DevOps? Let’s break it down:

Feature	Octopus Deploy	Jenkins	GitHub Actions	Azure DevOps
Ease of Use	⭐⭐⭐⭐⭐ (Super user-friendly)	⭐⭐ (Good luck with XML hell)	⭐⭐⭐ (Pretty nice)	⭐⭐⭐⭐ (Solid UI)
Deployment Focus	✅ (Built for deployments)	❌ (More of a CI tool)	❌ (More of a CI tool)	✅ (Supports CD, but complex)
Multi-Environment Support	✅	⚠️ (Requires plugins)	⚠️ (Workarounds needed)	✅
Rollback Features	✅ (Super easy)	⚠️ (Painful)	❌ (Not built-in)	✅ (But tricky)
Security & Access Control	✅ (Granular permissions)	⚠️ (Plugins needed)	⚠️ (Limited)	✅ (Enterprise-ready)
Integrations	✅ (All major platforms)	✅ (Through plugins)	✅ (But limited)	✅ (Best with Azure)

Code Examples: Deploy Like a Pro

1. Create a New Deployment Project

1

octo create-project --project "My Awesome App" --server "https://octopus.example.com" --apiKey "API-KEY"

2. Deploy a Release

1

octo deploy-release --project "My Awesome App" --releaseNumber "1.2.3" --deployTo "Production"

3. Create a New Release

1

octo create-release --project "My Awesome App" --version "1.2.3" --packageVersion "1.2.3"

4. List Available Environments

1

octo list-environments --server "https://octopus.example.com" --apiKey "API-KEY"

5. Push a Package to Octopus

1

octo push --package "MyApp.1.2.3.nupkg" --server "https://octopus.example.com" --apiKey "API-KEY"

6. View Deployment Logs

1

octo get-deployment --deploymentId "DEPLOYMENT-ID"

7. Promote a Release

1

octo promote-release --project "My Awesome App" --from "Staging" --to "Production"

8. Cancel a Deployment

1

octo cancel-deployment --deploymentId "DEPLOYMENT-ID"

9. List All Projects

1

octo list-projects --server "https://octopus.example.com" --apiKey "API-KEY"

10. View Deployment Progress

1

octo get-tasklog --taskId "TASK-ID"

Key Takeaways

Concept	Summary
History	Created in 2011 to simplify deployments
Purpose	Automates deployments, rollbacks, and multi-environment setups
Comparison	More deployment-focused than Jenkins, GitHub Actions, and Azure DevOps
Best Features	Rollbacks, security, environment management, and easy integrations
CLI Power	Automate everything using the Octopus CLI

References

Pulumi in a Nutshell

Thu, 10 Aug 2023 00:00:00 +0000

Pulumi is an Infrastructure as Code (IaC) tool that lets you define cloud infrastructure using real programming languages instead of domain-specific ones.

This means you can finally write your infrastructure like you write your applications.

If you’ve ever wished for loops and conditionals in Terraform, Pulumi is your new best friend.

A Brief History of Pulumi

Pulumi was founded in 2017 by some smart folks who decided that writing infrastructure in JSON, YAML, or HCL was painful.

Istead of creating Yet Another Configuration Language™, they made Pulumi, which lets you use Python, TypeScript, JavaScript, Go, and .NET to provision cloud resources.

Since its launch, Pulumi has gained traction as an alternative to Terraform, especially among developers who prefer using real programming languages to manage infrastructure.

Pulumi vs. Other IaC Tools

Feature	Pulumi	Terraform	CloudFormation	Ansible
Multi-Cloud	✅ Yes	✅ Yes	❌ No (AWS-only)	✅ Yes
Language	Python, JS, Go, .NET	HCL	YAML/JSON	YAML
State Management	Managed or self-hosted	Self-managed	AWS-managed	No state
Imperative or Declarative	Imperative	Declarative	Declarative	Imperative
Best For	DevOps & developers	DevOps teams	AWS-heavy shops	Config management

If you love programming, use Pulumi. If you want multi-cloud support but don’t mind HCL, use Terraform. If you only use AWS, CloudFormation is fine. If you just need to install software, Ansible is your go-to.

Common Pulumi Code Examples

1. Deploy an AWS S3 Bucket

1
2
3
4
5


import pulumi
import pulumi_aws as aws

bucket = aws.s3.Bucket("my-bucket")
pulumi.export("bucket_name", bucket.id)

2. Create an EC2 Instance

1
2
3
4


instance = aws.ec2.Instance("my-instance",
 ami="ami-12345678",
 instance_type="t2.micro")
pulumi.export("instance_id", instance.id)

3. Provision an RDS Database

1
2
3
4
5


db = aws.rds.Instance("my-db",
 engine="mysql",
 instance_class="db.t3.micro",
 allocated_storage=20)
pulumi.export("db_endpoint", db.endpoint)

4. Deploy a Kubernetes Cluster

1
2
3


import pulumi_kubernetes as k8s
cluster = k8s.core.v1.Namespace("my-namespace")
pulumi.export("namespace_name", cluster.metadata.name)

5. Create an IAM Role

1
2
3
4
5
6
7
8


role = aws.iam.Role("my-role",
 assume_role_policy="""
 {
 "Version": "2012-10-17",
 "Statement": [{"Effect": "Allow", "Principal": {"Service": "ec2.amazonaws.com"}, "Action": "sts:AssumeRole"}]
 }
 """)
pulumi.export("role_name", role.name)

6. Set Up a Load Balancer

1
2
3
4


lb = aws.lb.LoadBalancer("my-lb",
 internal=False,
 load_balancer_type="application")
pulumi.export("lb_dns", lb.dns_name)

7. Define a CloudWatch Alarm

1
2
3
4
5


alarm = aws.cloudwatch.MetricAlarm("my-alarm",
 comparison_operator="GreaterThanThreshold",
 threshold=80,
 evaluation_periods=2)
pulumi.export("alarm_arn", alarm.arn)

8. Use Pulumi Variables

1
2
3
4
5
6


import pulumi
from pulumi import Config

config = Config()
instance_type = config.get("instance_type") or "t2.micro"
pulumi.export("instance_type", instance_type)

9. Deploy a Static Website on S3

1
2
3


bucket = aws.s3.Bucket("website",
 website={"index_document": "index.html"})
pulumi.export("website_url", bucket.website_endpoint)

10. Automate Secret Management with AWS Secrets Manager

1
2


secret = aws.secretsmanager.Secret("my-secret")
pulumi.export("secret_id", secret.id)

Key Ideas Table

Concept	Explanation
Pulumi	IaC tool that uses real programming languages
Multi-cloud support	Works with AWS, Azure, GCP, Kubernetes, and more
State Management	Can be managed by Pulumi or self-hosted
Comparison	Competes with Terraform, CloudFormation, and Ansible
Example Uses	Provisioning VMs, Load Balancers, Kubernetes, and IAM roles

Reference Links

Bamboo in a nutshell

Wed, 01 Nov 2023 00:00:00 +0000

What is Bamboo?

Bamboo is Atlassian’s Continuous Integration (CI) and Continuous Deployment (CD) tool that makes sure your code doesn’t break every time Chad from QA pushes an update.

It’s like Jenkins but with a fancier UI and built-in Jira integration.

DevOps teams love it because it automates builds, tests, and releases, reducing the need for manual deployment drama.

A Brief History of Bamboo (Or How We Got Here)

Bamboo was launched by Atlassian in 2007, back when people still thought Subversion was the future.

Bamboo Integrates well with Atlassian’s ecosystem (Jira, Bitbucket, Confluence, and probably a few other tools nobody fully understands).

Infrastructure as Code (IaC) - The Big Picture

In the old days, setting up a new server meant physically plugging in machines, installing software manually, and praying to the IT gods.

Infrastructure as Code (IaC) changed that by letting us define infrastructure with code, so we can automate provisioning, configuration, and management.

Bamboo plays in the IaC world by integrating with Terraform, Ansible, and Kubernetes.

How Does Bamboo Compare to Other Tools?

🏆 Bamboo vs. Jenkins

Bamboo: Sleek UI, native Jira/Bitbucket integration, and better support.
Jenkins: Free and open-source but requires tons of plugins and setup.

🏆 Bamboo vs. GitLab CI/CD

Bamboo: Stronger Jira/Bitbucket integration.
GitLab CI/CD: Built directly into GitLab, no separate tool required.

🏆 Bamboo vs. CircleCI

Bamboo: Great for Atlassian users.
CircleCI: Strong cloud-based CI/CD with fast execution.

10 Common Bamboo Examples

1. Setting Up a Simple Build Plan

1
2
3
4
5
6
7
8
9


plan:
 key: MYPROJ-BUILD
 name: Build My Project
stages:
 - name: Build
 jobs:
 - name: Compile
 tasks:
 - script: mvn clean install

2. Running Unit Tests

1
2
3
4


jobs:
 - name: Test
 tasks:
 - script: mvn test

3. Deploying to Staging

1
2
3
4


jobs:
 - name: Deploy Staging
 tasks:
 - script: kubectl apply -f deployment.yaml

4. Checking Out Code from Git

1
2
3


repositories:
 - name: MyRepo
 url: https://bitbucket.org/myrepo.git

5. Building a Docker Image

1
2
3
4


jobs:
 - name: Build Docker Image
 tasks:
 - script: docker build -t my-app:latest .

6. Pushing Docker Image to Registry

1
2
3
4


jobs:
 - name: Push Docker Image
 tasks:
 - script: docker push my-app:latest

7. Running a Static Code Analysis

1
2
3
4


jobs:
 - name: Code Quality
 tasks:
 - script: sonar-scanner

8. Sending Notifications to Slack

1
2
3
4


jobs:
 - name: Notify Slack
 tasks:
 - script: curl -X POST -H "Content-Type: application/json" -d '{"text":"Build completed!"}' https://hooks.slack.com/services/XXX

9. Deploying to Production

1
2
3
4


jobs:
 - name: Deploy Prod
 tasks:
 - script: ansible-playbook deploy.yml

10. Running a Performance Test

1
2
3
4


jobs:
 - name: Load Test
 tasks:
 - script: locust -f load_test.py

Key Ideas

Topic	Summary
What is Bamboo?	A CI/CD tool by Atlassian for automating builds, tests, and deployments.
History	Launched in 2007, optimized for Atlassian tools.
Infrastructure as Code	Automates infrastructure deployment alongside code.
Comparison	Competes with Jenkins, GitLab CI/CD, and CircleCI.
Common Usage	Automating builds, testing, deployment, and notifications.

Reference Links

AWS CloudFormation in a Nutshell

Mon, 28 Mar 2022 00:00:00 +0000

A Brief History of AWS CloudFormation

Back in 2011, AWS decided to make life easier by introducing CloudFormation, a tool that allows engineers to define AWS infrastructure in JSON (or YAML, if you have taste).

Before this, people had to:

Manually create resources through the AWS Console 😵
Write long, fragile bash scripts to automate deployments 🔧
Cry when their cloud environment wasn’t repeatable 😭

AWS CloudFormation vs. Other IaC Tools

Feature	CloudFormation	Terraform	Pulumi	Ansible
AWS-Native	✅ Yes	❌ No	❌ No	❌ No
Multi-Cloud Support	❌ No	✅ Yes	✅ Yes	✅ Yes
Language	YAML/JSON	HCL	Python/JS/Go	YAML
State Management	AWS Managed	Self-managed	Self-managed	No explicit state
Best For	AWS-only infra	Multi-cloud infra	Devs who prefer real code	Config management

If you’re all-in on AWS, CloudFormation is a solid choice.

If you need multi-cloud support, Terraform is your best bet.

Pulumi is for devs who hate YAML, and Ansible is for managing software/configurations rather than provisioning infra.

CloudFormation Code Examples

1. Create an S3 Bucket

1
2
3
4
5
6


AWSTemplateFormatVersion: '2010-09-09'
Resources:
 MyS3Bucket:
 Type: "AWS::S3::Bucket"
 Properties:
 BucketName: "my-cloudformation-bucket"

2. Provision an EC2 Instance

1
2
3
4
5
6


Resources:
 MyEC2Instance:
 Type: "AWS::EC2::Instance"
 Properties:
 InstanceType: "t2.micro"
 ImageId: "ami-12345678"

3. Set Up a VPC

1
2
3
4
5


Resources:
 MyVPC:
 Type: "AWS::EC2::VPC"
 Properties:
 CidrBlock: "10.0.0.0/16"

4. Deploy a Load Balancer

1
2
3
4
5
6


Resources:
 MyLoadBalancer:
 Type: "AWS::ElasticLoadBalancingV2::LoadBalancer"
 Properties:
 Name: "my-load-balancer"
 Type: "application"

5. Spin Up an RDS Database

1
2
3
4
5
6
7


Resources:
 MyRDS:
 Type: "AWS::RDS::DBInstance"
 Properties:
 Engine: "mysql"
 DBInstanceClass: "db.t3.micro"
 AllocatedStorage: 20

6. Create an IAM Role

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


Resources:
 MyIAMRole:
 Type: "AWS::IAM::Role"
 Properties:
 RoleName: "MyCloudFormationRole"
 AssumeRolePolicyDocument:
 Version: "2012-10-17"
 Statement:
 - Effect: "Allow"
 Principal:
 Service: "ec2.amazonaws.com"
 Action: "sts:AssumeRole"

7. Set Up an Auto Scaling Group

1
2
3
4
5
6


Resources:
 MyAutoScalingGroup:
 Type: "AWS::AutoScaling::AutoScalingGroup"
 Properties:
 MinSize: "1"
 MaxSize: "5"

8. Deploy a Lambda Function

1
2
3
4
5
6
7
8


Resources:
 MyLambda:
 Type: "AWS::Lambda::Function"
 Properties:
 Runtime: "python3.8"
 Handler: "index.lambda_handler"
 Code:
 S3Bucket: "my-lambda-bucket"

1
2
3
4
5


Resources:
 MySNSTopic:
 Type: "AWS::SNS::Topic"
 Properties:
 DisplayName: "My SNS Topic"

10. Define a CloudWatch Alarm

1
2
3
4
5
6
7


Resources:
 MyCloudWatchAlarm:
 Type: "AWS::CloudWatch::Alarm"
 Properties:
 AlarmDescription: "High CPU usage"
 ComparisonOperator: "GreaterThanThreshold"
 Threshold: 80

Key Ideas Table

Concept	Explanation
CloudFormation	AWS-native IaC tool (YAML/JSON)
State Management	AWS manages state internally
Best Use Case	Deploying AWS-only infrastructure
Comparison	Competes with Terraform, Pulumi, and Ansible
Example Uses	Provisioning VMs, databases, networks, and IAM roles

Reference Links

Understanding AWS CloudFormation, Terraform, Pulumi, and Ansible

Fri, 19 Aug 2022 00:00:00 +0000

What is Infrastructure as Code (IaC)? 🤔

Before we go full throttle, let’s define Infrastructure as Code.

IaC is the practice of managing and provisioning infrastructure through code instead of manually clicking around AWS like a lost intern. It lets you:

✅ Automate deployments 🔄
✅ Keep infrastructure consistent across environments 🌍
✅ Easily roll back changes when things inevitably break 😅
✅ Version control your infrastructure just like application code 📜

Now, let’s talk about the key players in the IaC world.

The History of IaC Tools

AWS CloudFormation (2011) - The AWS Native Solution ☁️

AWS CloudFormation was Amazon’s first major attempt at automating infrastructure. Using YAML/JSON templates, you could define AWS resources and deploy them in a predictable, repeatable way.

👉 Think of CloudFormation as: That AWS employee who only uses AWS-approved tools and thinks everything else is unnecessary. 😆

More on CloudFormation: https://aws.amazon.com/cloudformation/

Terraform (2014) - The Multi-Cloud King 👑

Terraform, built by HashiCorp, changed the game by introducing a declarative, cloud-agnostic approach to IaC using its own language called HCL (HashiCorp Configuration Language).

👉 Think of Terraform as: That developer who insists on supporting AWS, Azure, and GCP all at once. 🌍

More on Terraform: https://www.terraform.io/

Pulumi (2018) - IaC with Real Code 💻

Pulumi took a different route: instead of using YAML/HCL, it lets you define infrastructure using real programming languages like Python, JavaScript, and Go.

👉 Think of Pulumi as: That cool DevOps engineer who writes infrastructure in TypeScript because “everything should be JavaScript!”

Ansible (2012) - Configuration Management Meets IaC ⚙️

Ansible started as a configuration management tool but evolved into an IaC powerhouse. It uses YAML playbooks to define infrastructure and automate deployments.

👉 Think of Ansible as: The reliable sysadmin who believes “everything can be fixed with a YAML playbook!”

More on Ansible: https://www.ansible.com/

How They Compare: CloudFormation vs Terraform vs Pulumi vs Ansible

Feature	CloudFormation	Terraform	Pulumi	Ansible
Multi-Cloud	No (AWS-only)	Yes	Yes	Yes
Language	YAML/JSON	HCL	Python/JS/Go	YAML
State Management	AWS Manages	Self-managed	Self-managed	No explicit state
Ease of Use	Medium	Medium	Harder (code-heavy)	Easy
Best for	AWS-only setups	Multi-cloud infra	DevOps with coding	Server Configs

Example Code for Each IaC Tool

AWS CloudFormation Example (Creates an S3 Bucket)

1
2
3
4
5
6


AWSTemplateFormatVersion: '2010-09-09'
Resources:
 MyS3Bucket:
 Type: "AWS::S3::Bucket"
 Properties:
 BucketName: "my-cloudformation-bucket"

Terraform Example (Creates the Same S3 Bucket)

1
2
3
4
5
6
7


provider "aws" {
 region = "us-east-1"
}

resource "aws_s3_bucket" "my_bucket" {
 bucket = "my-terraform-bucket"
}

Pulumi Example (Python)

1
2
3
4
5


import pulumi
import pulumi_aws as aws

bucket = aws.s3.Bucket("my-pulumi-bucket")
pulumi.export("bucket_name", bucket.id)

Ansible Playbook Example (Deploys S3 Bucket)

1
2
3
4
5
6
7


- name: Create an S3 Bucket
 hosts: localhost
 tasks:
 - name: Create bucket
 amazon.aws.s3_bucket:
 name: my-ansible-bucket
 state: present

Key Ideas Table

Concept	Explanation
Infrastructure as Code	Automating infrastructure using code
CloudFormation	AWS-native IaC tool (YAML/JSON)
Terraform	Multi-cloud declarative IaC (HCL)
Pulumi	Code-based IaC using real languages (Python/JS)
Ansible	Configuration management + IaC (YAML Playbooks)

Reference Links

Bamboo vs Jenkins In Depth

Thu, 15 Dec 2022 00:00:00 +0000

The History of Jenkins and Bamboo

Jenkins: The Granddaddy of CI/CD 👴

Born in 2004 as Hudson at Sun Microsystems.
2011: Oracle acquires Sun ☠️, and the community forks Hudson to create Jenkins.
Now: The undisputed king of open-source CI/CD with thousands of plugins and community support.

👉 Think of Jenkins as that old Unix admin who knows everything but looks like he was programmed in 1995.

More on Jenkins: https://www.jenkins.io/

Bamboo: The Sleek Corporate Solution 🏢

Created by Atlassian in 2007.
Designed to integrate seamlessly with Bitbucket, Jira, and Confluence.
Supports Docker, Kubernetes, AWS, and integrates beautifully with enterprise environments.

👉 Think of Bamboo as the polished DevOps engineer who uses an iPad instead of a terminal.

More on Bamboo: https://www.atlassian.com/software/bamboo

Feature Comparison: Bamboo vs Jenkins

Feature	Jenkins	Bamboo
Ease of Use	Complex UI, requires plugins for simple tasks	Simple UI, built-in integrations
Scalability	Requires tuning, supports distributed builds	Scales out of the box with AWS, Docker, Kubernetes
Plugins & Extensibility	1800+ plugins, but chaotic	Fewer plugins, but structured
Built-in Features	Core is minimal; everything is a plugin	CI/CD, Deployment, Reporting, Bitbucket integration
Security	Community-managed updates, can be risky	Enterprise-level security, access controls
Cost	Free & open-source	Paid license for full features

Example CI/CD Pipelines: Jenkins vs Bamboo

Jenkins Pipeline Example

Here’s a basic Jenkinsfile to build a simple Node.js app.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


pipeline {
 agent any
 stages {
 stage('Build') {
 steps {
 sh 'npm install'
 }
 }
 stage('Test') {
 steps {
 sh 'npm test'
 }
 }
 stage('Deploy') {
 steps {
 sh 'npm run deploy'
 }
 }
 }
}

To set up this pipeline:

Install Jenkins.
Install the Pipeline plugin.
Create a new Multibranch Pipeline Job.
Point it to your Git repo with Jenkinsfile.

Bamboo Pipeline Example

Now, here’s a simple Bamboo build plan:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


stages:
 - stage: Build
 jobs:
 - job: Install and Test
 script:
 - npm install
 - npm test
 - stage: Deploy
 jobs:
 - job: Deploy to Staging
 script:
 - npm run deploy

To set this up:

Go to Bamboo.
Create a new Build Plan.
Add the Stages and Jobs.
Connect it to Bitbucket (if using Atlassian products).

When to Use Bamboo vs Jenkins

Use Case	Best Tool
You’re an enterprise using Bitbucket & Jira	🚀 Bamboo
You love open-source, flexibility, and don’t mind chaos	🤖 Jenkins
Security and structured enterprise support is critical	🏢 Bamboo
You want a free solution with a massive community	🌍 Jenkins
You need rapid, plugin-driven customization	🛠️ Jenkins
You prefer built-in CI/CD with less maintenance	🏆 Bamboo

Final Verdict

If you’re a startup or love open-source freedom → Use Jenkins (but be ready for some plugin mayhem). 🎭
If you’re in an enterprise using Atlassian tools → Use Bamboo (less headache, better integration). 🏢

Whichever you choose, both Bamboo and Jenkins are awesome in their own way. Pick what fits your stack and DevOps culture best! 🚀

Key Ideas Table

Topic	Summary
Jenkins	Open-source, highly flexible but requires plugins
Bamboo	Enterprise CI/CD solution with strong Bitbucket integration
Ease of Use	Bamboo is more user-friendly; Jenkins is powerful but complex
Security	Bamboo has better built-in security; Jenkins relies on community updates
Cost	Jenkins is free; Bamboo is paid
Example Pipelines	Showcased a basic Jenkinsfile and Bamboo YAML pipeline

Reference Links

Conclusion

So there you have it! Bamboo vs Jenkins, the ultimate showdown. Whether you want Jenkins’ flexibility or Bamboo’s tight Atlassian integration, both are solid choices. Now go forth and automate! 🚀🔥

OpenAPI-Use Jenkins to Detect OpenAPI Changes + Email Docs Team

Tue, 23 Jul 2019 00:00:00 +0000

So, you’re maintaining manual API documentation, but how do you know when to update it?

If your API changes, but nobody tells the documentation team… you’ve got a problem.

What if Jenkins could:
✅ Detect when swagger.json changes
✅ Log the differences in a file
✅ Trigger a documentation update notification
✅ Fail the build if documentation updates are ignored

🔥 The Plan

We’re setting up two Jenkins jobs to monitor OpenAPI changes:

1️⃣ API Repo Jenkins Job – Detects changes in swagger.json and logs them in a apichangessensedbyjenkins.txt file.
2️⃣ Docs Repo Jenkins Job – Watches for changes in this file and emails the doc team with the API diff.

If the diff logging fails, the API build fails.
If documentation updates are ignored, a reminder email is sent.

🛠 Step 1: Set Up Jenkins to Detect OpenAPI Changes

✅ 1.1: Install Required Tools on Jenkins Server

Make sure Jenkins has:

Git (apt install git or choco install git)
jq (JSON diff tool, apt install jq or choco install jq)
diff (should be pre-installed)

✅ 1.2: Create Jenkins Job to Detect API Changes

Open Jenkins Dashboard → New Item → Freestyle Project
Name it Detect-OpenAPI-Changes
Under Source Code Management, choose Git, and add your API repo URL.
Under Build Triggers, enable Poll SCM (e.g., every 5 minutes: H/5 * * * *).
Add the following Bash Script under Build Steps → Execute Shell:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46


#!/bin/bash

# Define paths
API_REPO="/var/lib/jenkins/workspace/Detect-OpenAPI-Changes"
DOCS_REPO="/var/lib/jenkins/workspace/API-Docs-Changes"
SWAGGER_FILE="$API_REPO/swagger.json"
OLD_SWAGGER_FILE="$API_REPO/old_swagger.json"
CHANGE_LOG="$DOCS_REPO/apichangessensedbyjenkins.txt"

# Clone docs repo
if [ ! -d "$DOCS_REPO" ]; then
 git clone git@github.com:your-org/api-docs.git "$DOCS_REPO"
fi

# Pull latest changes
cd "$DOCS_REPO"
git pull origin main

# Check if old swagger file exists
if [ -f "$OLD_SWAGGER_FILE" ]; then
 # Compute JSON diff
 DIFF=$(diff <(jq -S . "$OLD_SWAGGER_FILE") <(jq -S . "$SWAGGER_FILE"))

 if [ "$DIFF" != "" ]; then
 echo "Swagger JSON has changed!"

 # Append diff to log file
 echo "----------------------------" >> "$CHANGE_LOG"
 echo "Date: $(date)" >> "$CHANGE_LOG"
 echo "Commit: $(git -C "$API_REPO" rev-parse HEAD)" >> "$CHANGE_LOG"
 echo "Changes:" >> "$CHANGE_LOG"
 echo "$DIFF" >> "$CHANGE_LOG"

 # Push changes to docs repo
 git add "$CHANGE_LOG"
 git commit -m "API changes detected by Jenkins on $(date)"
 git push origin main
 else
 echo "No changes detected in Swagger JSON."
 fi
else
 echo "First run, saving initial Swagger file."
fi

# Save new Swagger file for future comparison
cp "$SWAGGER_FILE" "$OLD_SWAGGER_FILE"

Save and Build Now.
Check if apichangessensedbyjenkins.txt is created/updated in your API-Docs repo.

📩 Step 2: Set Up Jenkins to Notify the Documentation Team

✅ 2.1: Create a Second Jenkins Job

Open Jenkins Dashboard → New Item → Freestyle Project
Name it Notify-Docs-Team
Under Source Code Management, choose Git, and add the API-Docs repo URL.
Under Build Triggers, enable Poll SCM (H/5 * * * *).
Under Build Steps → Execute Shell, add:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


#!/bin/bash

DOCS_REPO="/var/lib/jenkins/workspace/API-Docs-Changes"
CHANGE_LOG="$DOCS_REPO/apichangessensedbyjenkins.txt"

# Pull latest changes
cd "$DOCS_REPO"
git pull origin main

# Check if file has been updated
if git diff --name-only HEAD~1 HEAD | grep -q "apichangessensedbyjenkins.txt"; then
 echo "Swagger changes detected! Sending email notification..."

 # Extract last changes
 DIFF_CONTENT=$(tail -n 20 "$CHANGE_LOG")

 # Send email
 echo -e "Subject: API Documentation Update Required\n\nThe following API changes were detected:\n\n$DIFF_CONTENT" | sendmail -v docs-team@example.com
else
 echo "No new API changes detected."
fi

Save and Build Now.
Check email inbox for API change notifications.

🚨 Step 3: Fail Build if API Docs Aren’t Updated

If the documentation team doesn’t update the API docs (by updating the swagger.json) after changes, we can fail the build.

In Notify-Docs-Team, go to Post-Build Actions → Add Post-Build Script
Add the following check:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


#!/bin/bash

DOCS_REPO="/var/lib/jenkins/workspace/API-Docs-Changes"
CHANGE_LOG="$DOCS_REPO/apichangessensedbyjenkins.txt"

# Get last commit message
LAST_COMMIT_MSG=$(git -C "$DOCS_REPO" log -1 --pretty=%B)

# If the last commit was by Jenkins, the docs haven't been updated yet
if [[ "$LAST_COMMIT_MSG" == *"API changes detected by Jenkins"* ]]; then
 echo "Documentation has not been updated. Failing build."
 exit 1
else
 echo "Documentation updated. Build successful."
fi

Now, if the docs team doesn’t update API documentation, the build will fail, forcing them to take action.

So, Jenkins is now detecting API changes, logging diffs, and failing the build if documentation isn’t updated. Great!

But now the docs team has a new problem:
➡️ How do they actually update the Swagger JSON and prevent build failures?

The answer? A simple Python script.
(Which is the answer to most things in life hahaha.. )

How The Docs Team can push a button after the docs are fix- and make the build work again

🚀 The Plan

The docs team will:
✅ Run a Python script to pull the latest swagger.json
✅ Manually review and update the documentation
✅ Commit and push the updated swagger.json
✅ Fix the Jenkins failure, keeping API docs up to date

Let’s build it. 🚀

🔧 Step 1: Install Dependencies

The script uses GitPython to manage Git operations and jsondiff to detect changes in swagger.json.

Install them with:

1

pip install gitpython jsondiff

📝 Step 2: Create the Python Script

Save the following script as update_swagger.py in the manual documentation repository.

 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102


import os
import json
import git
import subprocess
from jsondiff import diff

# Set repository paths
DOCS_REPO_PATH = os.path.abspath(".") # Run this script inside the docs repo
API_REPO_URL = "git@github.com:your-org/api-repo.git" # API repository
TEMP_CLONE_PATH = "/tmp/api-repo" # Temporary API clone location
SWAGGER_FILE = "swagger.json"
CHANGE_LOG_FILE = "apichangessensedbyjenkins.txt"

def clone_api_repo():
 """Clone the API repository to fetch the latest swagger.json."""
 if os.path.exists(TEMP_CLONE_PATH):
 subprocess.run(["rm", "-rf", TEMP_CLONE_PATH], check=True)

 print("Cloning API repository...")
 git.Repo.clone_from(API_REPO_URL, TEMP_CLONE_PATH)

def fetch_swagger_file():
 """Fetch the latest swagger.json from the API repo."""
 api_swagger_path = os.path.join(TEMP_CLONE_PATH, SWAGGER_FILE)

 if not os.path.exists(api_swagger_path):
 raise FileNotFoundError("Swagger file not found in API repository!")

 with open(api_swagger_path, "r") as f:
 return json.load(f)

def load_current_swagger():
 """Load the existing swagger.json from the docs repo."""
 docs_swagger_path = os.path.join(DOCS_REPO_PATH, SWAGGER_FILE)

 if not os.path.exists(docs_swagger_path):
 print("No existing swagger.json found. Creating a new one...")
 return {}

 with open(docs_swagger_path, "r") as f:
 return json.load(f)

def detect_changes(old, new):
 """Detect changes between old and new Swagger JSON."""
 return diff(old, new, syntax="symmetric")

def update_swagger_file(new_swagger):
 """Update the local swagger.json file in the documentation repo."""
 docs_swagger_path = os.path.join(DOCS_REPO_PATH, SWAGGER_FILE)

 with open(docs_swagger_path, "w") as f:
 json.dump(new_swagger, f, indent=2)

 print(f"Updated {SWAGGER_FILE} with the latest API changes.")

def append_to_changelog(changes):
 """Append detected changes to the Jenkins change log file."""
 changelog_path = os.path.join(DOCS_REPO_PATH, CHANGE_LOG_FILE)

 with open(changelog_path, "a") as f:
 f.write("\n----------------------------\n")
 f.write(f"Date: {subprocess.getoutput('date')}\n")
 f.write(f"Changes detected:\n{json.dumps(changes, indent=2)}\n")

 print(f"Changes appended to {CHANGE_LOG_FILE}.")

def commit_and_push():
 """Commit and push the updated swagger.json to prevent Jenkins build failure."""
 repo = git.Repo(DOCS_REPO_PATH)

 repo.git.add(SWAGGER_FILE)
 repo.git.add(CHANGE_LOG_FILE)

 commit_message = "Updated Swagger JSON to match API changes."
 repo.git.commit("-m", commit_message)

 print("Pushing changes to documentation repository...")
 repo.git.push("origin", "main")

 print("Swagger JSON updated and pushed successfully!")

if __name__ == "__main__":
 try:
 clone_api_repo()

 new_swagger = fetch_swagger_file()
 old_swagger = load_current_swagger()

 changes = detect_changes(old_swagger, new_swagger)

 if changes:
 print("Changes detected! Updating documentation...")
 update_swagger_file(new_swagger)
 append_to_changelog(changes)
 commit_and_push()
 print("✅ Documentation successfully updated.")
 else:
 print("No changes detected. Documentation is already up to date.")

 except Exception as e:
 print(f"❌ Error: {e}")
 exit(1)

📌 Step 3: Run the Script

The documentation team can now update the API docs with:

1

python update_swagger.py

🔥 Step 4: Automate Updates with Jenkins

If the docs team wants to automate this, add it to Jenkins:

Open Jenkins Dashboard → New Item → Freestyle Project
Name it Update-Swagger-Docs
Under Source Code Management, choose Git, and add the documentation repo URL
Under Build Triggers, enable Poll SCM (H/10 * * * *).
Under Build Steps → Execute Shell, add:

1
2
3
4
5


#!/bin/bash

cd /var/lib/jenkins/workspace/API-Docs
git pull origin main
python3 update_swagger.py