Thinking SDLC On Codiac
What Is An SDLC?
The Software Development Lifecycle (SDLC) is in every aspect of your tech career. From the idea you or someone else has for a product to the clusters running the software/application stack(s) to the software running on the clusters in various environments (Dev, Staging, QA, Prod, etc.). From inception to release, SDLC is there.
SDLC is broken up into seven stages:
- Project Planning: One simple question - “What do we want?”. It all comes down to what the end goal is (or at least the current plan for the end goal).
- Requirement Gathering: Take note of all requirements that the product will need. What are the prerequisites? Any dependencies? What environment (cloud, on-prem, virtual, etc.) will it be running on?
- Design: This is the architecture phase. Once the project is planned and you know the requirements, you can start mapping it out.
- Implementation: This is the building (writing the code) and implementation phase The “implementation” piece is specifically for Dev and UAT/Staging environments as step 6 will be for the actual production deployment.
- Testing: QA departments go in and test to confirm that what’s deployed and written is what’s expected. In a Test-Driven Development (TDD) environment, this step may come before step 4 (implementation).
- Deployment: Stage 6 is the actual deployment to production.
- Maintenance: Upgrades, updates, bug fixes, etc.
Now that you know the seven stages, let’s learn about the SDLC models (you may have already heard of a few of them).
SDLC Models
There are three SDLC models:
- Waterfall
- Agile
- Iterative
Waterfall was the primary method for a long time and depending on the organization, it may still be. It’s a slower approach to software development in terms of building, deploying, and innovation. For example, with a Waterfall model, you may only deploy a new software version once per year (or longer). It’s all about one big change as infrequently as possible.
Agile on the other hand is the new normal. Instead of deploying once per year, you could be deploying multiple times per day. It’s all about incremental changes vs one big change like in Waterfall.
Iterative is all about repetition. It’s the deployment of environments as quick as possible and as repetitive as possible. You don’t see this model used too much because it can accrue a lot unused environments and therefore a lot of extra cost for no reason. With the background in SDLC and SDLC Models, let’s dive into where Codiac fits in.
Where Codiac Fits In
You can use Codiac for all stages of SDLC, but you’ll primarily see it used in:
- Design
- Implementation
- Testing
- Deployment
- Maintenance
Luckily, Codiac has you covered in just about every step of the SDLC. Let’s break down scenarios by Codiac feature.
Design
The first step is design, which is all about the architecture. How do you want the environment to look?
In Codiac, you have two primarily components when it comes to architecture:
Environment and Asset.An environment is what stage (Dev, Staging, Prod) you want to deploy to and what Kubernetes cluster will be in the environment.
The next step is the Cabinet. A Codiac Cabinet is a collection of Assets. An Asset could be anything from a Kubernetes Secret Manifest to a container image.
The final step in the Design phase is to think about what the environment will consist of. How many assets will there be? What type of assets will they be? You get to manage it all directly on Codiac.
You don’t have to add anything just yet, but getting a visual for where you want Assets to exist and how you want an Environment to look is crucial for the design stage.
Implementation
The next step is Implementation. Remember, this is all about coding up the product and ensuring that there are proper environments to work on what you’re coding. One step is to add some Development and Staging environments.
When you add environments, you’ll want to ensure that you choose the proper clusters that should be used within each environment.
After environments are implemented with proper clusters, you can begin taking look at the Assets you want within each environment, deploy the assets, and begin modification/updates/testing of the Asset.
These modifications and updates will be key to the next phase, Testing.
Testing At the Testing stage, some code may be written, Assets may be created, and modifications begin to take shape.
You’ve most likely already done this within the Implementation stage, but if not, you’ll need a Kubernetes cluster deployed to begin testing. Within Codiac, you can use the codiac noc cluster create command to deploy a Kubernetes cluster within your selected cloud provider and manage it in Codiac.
Within the testing phase in Codiac, chances are you’ll want to confirm that Assets work as expected and are implemented in a desired way. For example, is the name correct? How about the container image name? Is the port that the container listening on valid and available (or is it blocked behind a firewall?).
In the Testing phase, you should confirm that the clusters running within an environment are correct and the Assets you’ve deployed are configured as expected.
Deployment
At the Deployment stage, you’re preparing for what may be a production release. The release will consist of:
- The right environment
- Cabinets configured with Assets
- Assets that have the correct configurations
During the Deployment stage, it’s a great idea to double-check the environment. As an example, take a look at the Stage cabinet configs. I took a look at the Asset and realized that it may be a good idea to configure the footprint. The footprint contains resource limits and Pod options for replica count. In this case, I specified one replica.
The majority of issues come from misconfigurations, and those misconfigurations are most likely mistakes. Double-check configurations.
Maintenance
Last but certainly not least is the Day Two Ops piece, or in other words, the Maintenance stage.
With a quick example, think about resources. When a new environment and application stack gets deployed, it may not work as expected, and this is expected. For example, think about resource optimization. It’s possible that you could have an Asset that needs more CPU than originally anticipated, so you can go into the Codiac Cabinet configs and modify the CPU Limit.
Closing Thoughts
Think, understand, digest, create. Those four keywords make you more pragmatic in your engineering career and in what you deem appropriate to deploy. With the Software Development Lifecycle in your thought process, you can create beautiful software, and you can create beautiful software with the help of Codiac.
