Brief Look Into CI/CD
I’m a new Software Engineer on the quest for a job. So far, I’ve come across several languages that are repeatedly listed: JavaScript, TypeScript, Python, Go, Ruby, Java, C++, C# etc.
And then there are frameworks: React.js, Angular, Bootstrap, jQuery, Apache Spark etc.
And more qualifications to be familiar with: Node.js, AWS and cloud computing, SCRUM, Kubernetes etc.
It makes job hunting equal parts daunting yet exciting as I figure out which direction I want to head in my career.
Then, there is CI/CD. I have no idea what this stands for; I can’t even guess. But, I’m about to find out!
Continuous Integration and Continuous Delivery
According to Isaac Sacolick at InfoWorld, it is “one of the best practices for DevOps teams to implement, for delivering code changes more frequently and reliably.”
“a culture, set of operating principles, and collection of practices”
Oh, really! Kind of reminds me of how we’re told to frequently commit our work to save ourselves the trouble later down the road. And, in a team environment this reduces redundancies and merge conflicts.
And that’s exactly what ‘continuous integration’ is. A coding philosophy to “implement small changes and check in code to version control repositories frequently.” So, it’s continuous building, testing and integrating for better software quality.
Since most teams work with several environments, ‘continuous delivery’ is frequently pushing code changes to all those environments.
Tools are used to ensure everything necessary for all those environments goes out with each delivery. Some processes are automated between servers and databases when applications are deployed.
This smooth streamlined process allows some teams to deploy to production daily (even hourly).
Conclusion
There’s definitely more to it but, basically it seems like an optimized workflow where the development and operations teams work with DevOps and/or Site Reliability Engineers to continuously integrate, test, deliver and deploy.
