A lot of CI/CD tutorials show a simple “Hello World” app and a Jenkins job that prints Build Successful. That never felt close to how systems work in real environments. At least, they never helped me.

So I decided to build a small University Management Spring Boot monolith application with JWT authentication and protected APIs, and then build a complete pipeline around it — from source control to deployment, quality checks, security scans, artifact management and validation. Since I’m not a developer, the code itself isn’t great it was just me exploring a new language along with some help from AI (Needless to say!)

The application itself is intentionally simple:

• JWT-based authentication (/auth/login)
• Protected APIs (/students)
• Spring Security integration
• Maven build and Docker packaging

The goal wasn’t to show how to build an application (In that case, this would be the worst tutorial). Th goal is, to show a CI/CD(partly) flow to someone in less than 15 minutes.

So I created a mini DevSecOps pipeline that includes:

• GitHub webhooks
• Jenkins Controller + Agent
• SonarQube quality gates
• Docker image creation
• Trivy security scans
• Nexus artifact storage
• Automated deployment using Docker Compose

Just incase, anyone’s interested in the code, it stays here

By the end, a Git push automatically builds, scans, deploys and validates the application.

*The diagram: *

The App:

• Register using the /auth/register API

[root@server1 config]# curl -v -X POST "http://localhost:8081/auth/register?username=ram&password=redhat123"

• Pass the credentials to the /auth/login API to login . The App will return a JWT token, which will then be used to interact with the API.

[root@server1 config]# curl -X POST 
"http://localhost:8081/auth/login?username=ram&password=redhat123"
eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJyYW0iLCJpYXQiOjE3NzkxNzA4MjIsImV4cCI6MTc3OTE3NDQyMn0.4AwQQqEa07f_-YId7LSlXYnctaWf7TdqG6xPYxTum_4

• This step is actually not required, just a part of convenience.

[root@server1 config]# export TOKEN=eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJyYW0iLCJpYXQiOjE3NzkxNzA4MjIsImV4cCI6MTc3OTE3NDQyMn0.4AwQQqEa07f_-YId7LSlXYnctaWf7TdqG6xPYxTum_4

• Create entries using the JWT token to authenticate using the /students API.

[root@server1 config]# curl -X POST 
http://localhost:8081/students 
-H "Authorization: Bearer $TOKEN" 
-H "Content-Type: application/json" 
-d '{
"name":"John",
"email":"[email protected]"
}'
{"id":1,"name":"John","email":"[email protected]"}

• Query the API using the token.

[root@server1 config]# curl -H "Authorization: Bearer $TOKEN" http://localhost:8081/students;echo
[{"id":1,"name":"John","email":"[email protected]"}]

The pipeline:

• We will make use of Jenkins to run the pipeline.
• I have chosen to run the jobs off of a jenkins agent, simply to separate orchestration and execution

The very first stage of the pipeline after the developer pushes the code is to

• checkout the code from source control
• Build the application using Maven.

• The build generates a jar file, which is quite famously referred to as the artifact.
• Now, this artifact is scanned by our quality gates which checks it for any code smells, Bugs, Vulnerabilities, etc.

• The sonarqube interface shows something like:

My 2 cents: Do not forget to add Jenkins call back in Sonarqube, else the job in Jenkins will wait to get the status from sonarqube and will eventually timeout.

• If our code passes quality gates, we build the docker image and bake the artifact into the image.

• Earlier, we scanned for vulnerabilities, bugs in the code. Now, it’s time to scan for vulnerabilities in the docker image. I used Trivy for this. The ideal way to do this is to exit the job when there are vulnerabilities in the image. But for this lab I’m just running the scan as the image i pulled had loads of them.

• Additionally, I also posted the scan results on a nexus repository with the job number appended.

• This is the smallest CD part of the pipeline where we bring up the app using the image we built earlier using docker-compose.

• Finally, keeping the artifact on the agent is not a good idea, so I moved it to a Nexus repo and ran a cleanup of the workspace to remove it from the agent.

Future enhancements: I must admit, this document is incomplete without :

• converting this to a microservice
• Moving the application to K8s or Openshift.
• Adding monitoring for our App.

In the previous post, I showed what you actually get from the GitHub Student Developer Pack and why it’s worth claiming if you’re learning to code.

Now let’s talk about the important part:

How do you actually get approved?

Because yes, GitHub can reject your application if your profile looks messy, your name doesn’t match your documents, or your account information feels suspicious.

So before you smash the “Apply” button, fix the basics first.

1. Set your legal name on GitHub 🪪

First, go to:

https://github.com/settings/profile

In the Name field, write your real legal name.

Not your nickname or backend_god_777
Your actual name.

This matters because GitHub may ask you to verify your student status with a document, and the name on your GitHub profile should match the name on that document.

Don’t lie here. It’s not worth it. If your name doesn’t match, you’re basically asking the verification system to slap your application into the rejection bin.

2. Fill in your billing information, but don’t add a card 💳

Next, go to:

https://github.com/settings/billing/payment_information

Scroll to Billing information and fill it in properly.

You need to add:

• First name
• Last name
• Real address
• City
• Country
• State / Province
• Postal / ZIP code

The VAT / GST ID field can be left empty if you don’t have one.

Important: you don’t need to add a payment card for this step. Just fill in the billing information so your account looks complete and consistent.

Again, don’t write random nonsense here.

If your GitHub profile says one thing, your billing information says another thing, and your student document says something completely different, the verification system will not magically trust you.

It will probably just reject you and go drink coffee somewhere.

3. Apply for GitHub Education benefits 🎓

Now go to:

https://github.com/settings/education/benefits

This is where you apply for the GitHub Student Developer Pack.

Fill in the required information carefully. Choose your school/college/university, add the requested details, and submit your application.

GitHub may ask you to verify that you’re actually a student. Depending on your case, this can include things like a student email, school-issued document, student ID, transcript, or another proof of enrollment.

Make sure your document is readable, current, and matches the name you added earlier.

This is not the moment to upload a blurry potato photo taken from across the room.

4. Prepare a proper student document 📄

Before submitting the application, make sure your proof of student status actually looks official.

In my case, the document had:

• my first name and last name
• my class / grade
• the academic year
• the issue date of the certificate
• the signature of an authorized person
• the official blue round stamp / seal

That last part matters. A plain document with just your name typed on it may not be enough. GitHub needs to see that it came from a real educational institution, not from your “trust me bro” department.

Also, make sure the document is readable. No blurry photos, no weird angles, no dark screenshots where the text looks like ancient cave writing.

Your name on the document should match the legal name you added to your GitHub profile earlier. If the names don’t match, don’t be surprised if the verification system throws your application into the shadow realm.

5. Check your email 📩

After submitting your application, check your email.

If everything was submitted correctly, GitHub should send you a confirmation email saying they received your application. It may also give you an estimated date for when you should get a final response.

If you get rejected, don’t panic.

Read the reason carefully. Usually, it’s something boring but fixable:

• name mismatch
• unclear document
• expired proof
• wrong school information
• incomplete GitHub profile
• document doesn’t clearly show active enrollment

Fix the issue and apply again properly.

The goal is not to “trick” GitHub.

The goal is to make your information clean, consistent, and easy to verify.

6. Don’t rush the application 🧠

A lot of people get rejected because they apply too fast with a half-empty GitHub profile and messy account details.

Before applying, quickly check this:

• Your GitHub name matches your document
• Your billing information is filled in
• Your school information is correct
• Your document is clear and readable
• Your proof shows that you’re currently a student
• Your email is accessible

Small details matter here.

The verification system is not your friend. It doesn’t understand “bro trust me.”

It wants clean information.

Give it clean information.

Final checklist ✅

Before applying, do this:

1. Go to https://github.com/settings/profile and set your real legal name.
2. Go to https://github.com/settings/billing/payment_information and fill in your billing information.
3. Go to https://github.com/settings/education/benefits and submit your application.
4. Check your email for updates.
5. If GitHub asks for extra verification, send a clear and valid document.

That’s it.

No magic.
No shady tricks.
No fake data.

Just make your account look real, consistent, and verifiable.

I failed my first stats class in college.

Not because the math was hard. Because every example in the textbook was about iris flowers or Boston housing prices and I couldn’t figure out why anyone in real life would care. So the formulas just slid off my brain.

Years later, I’m a backend dev in Mumbai with a serious filter coffee habit and an even more serious sleep deficit. One Sunday morning, somewhere between my second tumbler of decoction and a half-broken Saturday deploy, I asked myself a question I could actually feel in my body: does more coffee actually mean I write more code?

That question is what finally taught me linear regression. Not the textbook. Not the YouTube playlist. A Google Sheet, my git log, and 30 cups of filter coffee.

Here’s the whole thing, including the math by hand, the part where I got it wrong, and the Python at the end.

The setup (and why I think most tutorials skip it)

Every linear regression tutorial I’d ever opened started with this line:

y = mx + b

And then immediately jumped into matrices. Cool. Useless.

The thing tutorials skip is what problem are you even trying to solve. Linear regression is, at its core, one question:

If I know X, can I make a reasonable guess at Y?

That’s it. If I know the size of a flat in Malad, can I guess the rent? If I know how many standup minutes I sat through, can I guess how many I actually retained? If I know how much coffee I drank today, can I guess how many lines of code I’ll commit?

I’m going to answer that last one.

The data I actually collected

For 30 weekdays I tracked two numbers:

• X: cups of filter coffee I drank that day (one tumbler = one cup, no chai counted)
• Y: lines of code I committed that day (net additions, from git log --shortstat)

Here are the first 10 rows. The full 30 are at the bottom of this post if you want to play with them yourself.

Before doing any math, Before doing any math, I dropped the numbers into a scatter plot maker and just sat with it for a minute. You should always do this first. Eyeballs are a free regression model.
and just looked at it. You should always do this first. Eyeballs are a free regression model.

What I saw: a clear-ish upward smear. Not a perfect line — day 5 (5 coffees → 305 lines) and day 10 (6 coffees → 360 lines) sit a bit off the trend, and day 7 (zero coffee, 40 lines) was the day there was a 4-hour power cut and I worked off my laptop battery in a café. But overall, more coffee, more code.

That smear is what linear regression turns into a number.

What we’re actually trying to find

We want to draw the single straight line that fits this cloud of points as well as possible.

A line has two parts:

• Slope (m): how many lines of code does one extra cup of coffee buy me?
• Intercept (b): how many lines of code do I write on a day with zero coffee?

If I find good values for m and b, then for any future day, I can plug in my coffee count and get a prediction.

But “fits as well as possible” — what does that mean? This is the bit that took me embarrassingly long to internalize.

The “least squares” idea, explained without the squares

Imagine I draw a random line through the cloud. For each real data point, there’s a gap between where the point actually is and where my line thinks it should be. That gap is called the residual — basically, how wrong the line was for that day.

If I add up all those gaps, I get a “total wrongness” score. The best line is the one with the smallest score.

One catch: some gaps are positive (line predicted too low), some are negative (predicted too high). If you just add them, they cancel each other out and you get a line that looks correct on paper but is actually terrible.

The fix is to square each gap before adding them. Negatives become positives, big mistakes get punished more than small ones, and now you have a real “wrongness” number worth minimizing.

That’s why it’s called least squares regression. We’re picking the line that makes the sum of squared gaps as small as possible.

That’s the whole intuition. The formulas below are just the calculus result of “find the m and b that minimize that sum.”

Doing it by hand on 5 data points

Let me use just 5 points so the numbers stay sane:

Step 1: averages.

• Mean of X: (2+4+1+3+5)/5 = 3
• Mean of Y: (142+287+95+210+305)/5 = 207.8

Step 2: deviations and products.

For each row I compute (X - meanX), (Y - meanY), their product, and (X - meanX)².

Sums: products = 565.0, squared deviations = 10.

Step 3: slope.

m = sum of products / sum of squared deviations
m = 565 / 10
m = 56.5

Step 4: intercept.

b = meanY - m * meanX
b = 207.8 - 56.5 * 3
b = 207.8 - 169.5
b = 38.3

So my fitted line is:

lines_of_code ≈ 56.5 * coffees + 38.3

Read in English: every extra cup of coffee buys me ~56 more lines of code, and on a zero-coffee day I’d still grind out about 38 lines. That intercept matches my power-cut day pretty well (40 lines).

I checked this against an online linear regression calculator and got the same numbers, which was nice — I’d been low-key worried I’d dropped a sign somewhere. (When you’re learning this, do the by-hand version and then verify with a tool. Two methods agreeing is how you know you actually understand it, not just memorized it.)

The mistake I made the first time

When I ran this on all 30 days, I got a slope of about 53 and an intercept of about 42. Close enough.

But then I made a prediction:

“If I drink 15 cups of coffee, I’ll write 53 × 15 + 42 = 837 lines of code.“

This is wrong, and it’s wrong in a way that’s worth understanding. My data only ranged from 0 to 6 cups of coffee. Predicting for 15 cups is called extrapolation, and a linear model has no idea that at 15 cups I would actually be in the ER, not in VS Code.

The relationship is probably linear-ish in the range I measured. Outside that range, all bets are off. Most real-world relationships curve, plateau, or break at some point. Linear regression is a local approximation, not a universal law.

This is the most common mistake I see beginners make, and honestly it’s the most common mistake I see in production dashboards too. “Our user growth was linear for six months, so we’ll hit ten lakh users by Q4.” No you won’t.

How good is my line, actually?

A line that’s “best” can still be terrible. Imagine if my data were a random cloud — there’d still be a best line, but it would predict nothing useful.

The standard score for this is R² (pronounced “R squared”). It’s a number between 0 and 1:

• R² = 1: the line passes through every point. Perfect.
• R² = 0: the line is no better than just guessing the average.
• R² = 0.7: the line explains about 70% of the variation in Y.

For my 30-day coffee experiment, R² came out to about 0.89. That’s strong — coffee really does seem to track my coding output. But correlation isn’t causation, and here’s where I have to be honest: on high-coffee days I was probably also more rested, more motivated, and not stuck in a 90-minute Outer Ring Road jam. The coffee might be a side effect of a productive day, not the cause of one.

Linear regression will happily fit a line. It will not tell you what causes what. That’s your job.

The Python version (5 lines)

Once you understand what’s happening, the code is almost a letdown:

import numpy as np

x = np.array([2, 4, 1, 3, 5, 2, 0, 4, 3, 6])
y = np.array([142, 287, 95, 210, 305, 160, 40, 250, 195, 360])

slope, intercept = np.polyfit(x, y, 1)
print(f"y = {slope:.1f}x + {intercept:.1f}")

If you want R² and the rest of the diagnostics, scipy.stats.linregress is the friendlier version:

from scipy.stats import linregress

result = linregress(x, y)
print(f"slope: {result.slope:.2f}")
print(f"intercept: {result.intercept:.2f}")
print(f"r-squared: {result.rvalue**2:.3f}")
print(f"p-value: {result.pvalue:.4f}")

The p-value is asking: “what’s the chance this slope is just noise?” Anything under 0.05 is the traditional cutoff for “probably real.” Mine came in at 1e-14, which means: almost certainly not a coincidence. (Doesn’t mean coffee causes code. Just means the relationship is real, whatever it is.)

When to reach for linear regression in real life

Honestly, more often than you’d think. Some boring-but-genuinely-useful examples from my own work:

• Estimating ticket resolution time from ticket length. Helps with sprint planning.
• Predicting cloud bill from monthly active users. Helps when pricing a new tier — and trust me, the finance team will ask.
• Figuring out at what page-load speed users start churning on a landing page. The slope tells you how many sign-ups each extra 100ms costs.
• Calibrating a sensor. If your IoT temperature reading drifts linearly off a reference thermometer, regression gives you the correction formula in two lines of Python.

The pattern is always the same: you have an X you can measure cheaply, and a Y you actually care about, and you want a quick “if I move the dial on X by this much, what happens to Y?”

It is not magic. It is a ruler. But it’s a ruler that knows about uncertainty, which is more than most rulers can claim.

What to try this week

If you want this to actually stick, don’t just read it. Pick something annoying in your life that has two numbers attached to it, and track it for two weeks.

Some ideas to steal:

• Hours of sleep vs. time-to-first-coffee (or chai) the next morning
• Number of standup attendees vs. how long it actually ran
• PRs opened that day vs. PRs you reviewed
• Daily commute minutes vs. how cranky you felt at the 6 PM standup

Plug it into any regression tool (I obviously used this one), look at the slope, and ask: does this number match my gut? If yes, you’ve quantified your intuition. If no, you’ve found something interesting.

That’s the whole point of stats, when you strip away the textbook flavor. It’s a tool for arguing with your own assumptions.

The full dataset

If you want to reproduce what I got, here’s all 30 days:

coffees = [2,4,1,3,5,2,0,4,3,6,2,3,4,1,5,3,2,4,5,1,3,4,2,6,3,4,2,5,3,4]
lines   = [142,287,95,210,305,160,40,250,195,360,170,225,260,80,330,
           205,150,265,310,90,200,255,165,355,200,270,155,315,210,275]

Drop those into the snippet above. You should get a slope around 53, intercept around 42, R² around 0.89.

And then go track something of your own. That’s when it actually clicks.

If you spot a math mistake, please yell at me in the comments. I’d rather be embarrassed than wrong.