What is an SDLC (software development lifecycle), and why is it important? We get asked this question so often we figured it was a good idea to make a blog post about it. For seasoned software engineers, this is just a way of life. Developers know this process as if it was their work manual. Their religion, if you will.
If you are an engineer or seasoned in PDLC or SDLC process, this post isn’t for you. This post simplifies a process that happens every day, sometimes a few times a day, to inform non-technical humans of what the lifecycle of a single line of code looks like in a healthy organization.
Is it not all just random?
You mean to say that developers don’t just sling code and make ideas come to life? You mean there is a rigorous process and gateways that code needs to go through from conception to working feature or service? Yes, and it’s something that every non-technical human needs to know, including founders, if you are working in SaaS or tech startup.
I mean, would you work in a kitchen if you didn’t know how a stove worked, or what a refrigerator was? I would hope not.
User stories and what it is you are building
A developer will have a ticket that is ready to be worked on. The anatomy of a ticket should include a user story with specs to know what to build. I add this into the SDLC process even though it is a part of the PDLC (product development lifecycle) primarily because the quality of your ticket will directly reflect the quality of the code written.
Make a copy of the code.
When the ticket/story is ready to be worked on, a developer will copy the master branch of the code repository and start writing the code for the feature requested on a copied version of the master codebase. They will name the branch/copy according to the ticket number they are working on.
Writing tests
The developer should not just be writing the code to make the feature, but they should also write something called unit and integration tests for this feature. These are a subset of code that is written to test the code they wrote for the feature. These tests will be run on a server to validate that their writing has a high validation score and arent breaking other parts of the application.
Cross-functional progression check-ins
The sprint is how developers get the work, and it is used as the secondary communication tool for the product team. The SDLC process has a lot of overlap with the PDLC (here is an article on PDLC). The main overlap between them is the agile methodology and ceremonies/meetings. The developers will assign an estimated point value (a gauge of difficulty) to each ticket they will be working on before a sprint starts. The developers will report the daily progression of the ticket/feature every morning with the product team on WIP (work in progress) items in the standup.
Pull request
Next, the developer will submit something called a pull request of his/her branch to the master branch of code to run the tests on the server and to gather feedback from peers on the code written. A pull request can not be merged into the master branch until the automated tests have passed and at least 2 of his/her peers have reviewed the code. The code review itself is a chance for everyone on the team to request changes to the code submit. Peer review comes in many forms, from requesting a code change due to coding best practices that the company has adopted to suggest the removal of a duplicate function to keep the code DRY (don’t repeat yourself).
When a pull request is submitted, this not only runs these features tests, but also runs the entire codebases tests. If any of the tests fail, the PR (pull request) and peer review will not occur until they pass. After all the tests have passed and peer review has taken place (any team suggestions have been remediated) and approved by the team, the pull request code can be merged into the master branch.
Wrap up
The above is an oversimplification of an SDLC process. Each of the sections above could warrant multiple blog posts diving deep into each step in the process on the tools and terminology. This post abstracted out hudge topics like branching by abstraction, CI/CD (continuous integration and deployment), protected branches, design patterns (the gang of four), and volumes of implementations of the SDLC process. The hope was to post something easy to consume for non-technical humans in a startup and educate them on a healthy SDLC process at a very high level.
