Did you ever feel tense while taking your exams? Or you must have watched the Olympics or other sports events like cricket, football, etc. When you focus on national players during significant events, you can observe stress and anxiety in performing at that level. Similar is the situation of an IT professional during a production deployment call. This moment is crucial because it represents the end of months or years of effort, the results of which will be evaluated by those involved. The stakes are high because the quality and success of the deployment can have a huge impact.
Teams follow a multi-step process called the SDLC (Software Development Life Cycle) model to manage this stress and increase success. These standards provide a framework to guide process improvement, reduce risk, and streamline deployment. The team’s goal is to follow this process and deliver quality software that meets the needs of stakeholders.
Some of the major SDLC models are:
- Waterfall Model
- V-Model
- Incremental Model
- RAD Model
- Iterative Model
Each SDLC model is suitable for a certain type of project. We can take the example of the Waterfall Model.
The SDLC Waterfall Model
- Requirements Analysis: Gather and document what the system should do.
- System Design: Outline the architecture and design specifications.
- Implementation: Write and integrate the code according to the design.
- Testing: Evaluate the system to ensure it meets the requirements.
- Deployment: Release the system for end-users to use.
- Maintenance: Address any issues or updates needed after deployment.
Structured approaches like SDLC emphasize planning, alignment, and risk management to ensure successful deployments. However, gaps can still lead to failures and negatively impact the client’s perception.
It is always a hassle when it comes to production deployment. It is simply your code for a service that will run as you developed it but in a different organization or environment. So, what’s the drill?
I can answer this by noting down some of the points I have understood from my IT experience.
1. Insufficient Requirement Gathering
Sometimes, demands are not appropriately explained in the documentation, stories, or any part of requirement gathering, but for some tasks, we just don’t have standards to track but understandings. If the process gets carried on, we may face delays in production planning or issues in production if deployed in such a case. Also, it can cause recurring problems in production.
For example, in one of the requirements meetings, we asked the client for the parameter’s details, but the client had no such information, which caused a delay in deployment.
2. Incorrect Dev/Sandbox Testing
Developers often test the service until a successful response and move it directly to production by getting approval. For TL/Manager, it is a win-win situation because service is delivered before the deadline until clients start playing Russian roulette.
Your (developers) poor approach is exposed now, and fixtures are happening live now in production. This affects the value of the business and the relationship with the client.
3. Inconsistency Between the Code in Lower Environment and Production
Most of the time, developers have to make changes to production services due to certain reasons, whether by team or client. At that time, it is necessary to have those changes tested in the Dev Organization/Environment first. Directly implementing those in production because of short-term liberty and approvals may do justice with the client and TL/Manager but not with your junior folks. They may not understand why code differences are there.
4. Improper or incomplete testing by the client
Note: This may be more for the production manager type of folks.
I have been through some of the developments and have reported the same behavior from some people that sometimes clients also rely on the developer in the testing part. The client knows the end-to-end project, and the developer is responsible for some part of it. So, the client side of testing is essential.
5. Pre-production testing
In most cases, the client doesn’t have test data for Pre-production to confirm the end-to-end working status of the service. This may cause failure of service. Always ask the client to do pre-production testing with real-time data and confirm the status of the service.
6. Load testing
Often, load testing is avoided when requirement gathering itself. It is necessary to have the service go through load testing so that if, at the production level, services start to receive more traffic than usual, we can trust the service’s capability to handle such cases.
That’s a wrap!
These gaps or processes need to be properly followed for a successful and hassle-free production deployment.
Perficient + Apigee
At Perficient, we create complex and robust integration solutions in Apigee, which helps our clients address the full spectrum of challenges with lasting solutions.
Contact us today to learn how we can help you to implement integration solutions with Apigee.
