Part 2: DevOps and the Workflows Around It
The moment my webpage loaded in the browser, served from an AWS EC2 instance, the whole session finally clicked. A few hours earlier, DevOps had been a word on a slide. Now it was something I had built and deployed myself.
This is Part 2 of my hands-on cloud series from Lakshya Connect at Parul University. In Part 1, we covered AWS fundamentals: IAM for permissions, EC2 for virtual servers, and S3 for storage. Day 2 was also led by Kinjal Gandhi and moved from understanding those pieces to using them in a real DevOps workflow.
Where Does Your Application Actually Run?
The session opened with a quick cloud computing recap, and then the instructor asked a question that quieted the room: once you’ve built an application, where does it actually run?
That question is where DevOps begins. A developer writes and tests code on their own machine, and it works there. Getting it running reliably for real users is a separate problem, and when the two sides work separately, the handoff brings manual steps, delays and confusion. DevOps addresses this through collaboration, automation and faster feedback between development and operations. We also looked at the DevOps lifecycle: plan, code, build, test, release, deploy and monitor, which then feeds back into planning. It’s a loop, not a straight line.
Git and GitHub: Version Control in Practice
Git tracks changes to your code on your own machine, and GitHub hosts that code so others can review it, collaborate on it and build on it. We created a repository, added a file, committed it and pushed it to GitHub. Doing it yourself is different from reading about commits and pushes in a tutorial. What I took from it is that a commit isn’t just saving a file. It’s a recorded, reversible step in the history of a project, and that history is what makes teamwork and safe changes possible.
CI/CD: Why Automation Matters
CI/CD stands for Continuous Integration and Continuous Deployment. Code is integrated frequently, tested automatically, and deployed once it passes. The reason this matters is that manual releases are repetitive and easy to get wrong in small ways. Automating the build, test and deployment steps cuts that repetitive work and makes every release follow the same process.
From Theory to Something Actually Live
This was the most valuable part of the two days. We took the EC2 instance from Day 1 and deployed a small webpage onto it. I wrote the page, pushed it to GitHub, deployed it to the server, and opened it in a browser to see it running.
The page itself was simple, but the experience connected everything. IAM, EC2, Git and deployment stopped being separate topics and became one path from code on my laptop to an application on a cloud server. Before this, I understood each concept individually. Afterward, I understood why they exist together.
The Wider DevOps Toolset
We finished with a short overview of tools that build on these foundations:
Docker packages applications into containers so they run the same way everywhere.
Terraform enables infrastructure as code, defining cloud resources in files instead of setting them up by hand.
Kubernetes orchestrates containers at scale.
Kinjal ma’am’s point stayed with me: the tool isn’t the goal, the process is.
What I Learned Across Both Days
Cloud computing gives you somewhere to run applications, and DevOps gives you a reliable way to get them there. Day 1 taught me the building blocks of AWS. Day 2 showed me the process that moves code from a laptop into those blocks consistently.
I wish to practice Git workflows on my own projects, set up a simple CI/CD pipeline with GitHub, and maybe explore Docker before moving on to infrastructure as code with Terraform.
Thank you, Kinjal Gandhi ma’am, for a genuinely hands-on session, and thank you to Lakshya Connect and Parul University for organizing it.
Top comments (0)