How do you update code in SDLC without disrupting software performance?

Branching allows to work on new features/Bug fixes without affecting main codebase. We always keep a MAIN branch stable as much as possible. Naming conventions for branch creation are useful. The tracking system should be user friendly & automated. Every single change that is going into the version control system is tracked to the reason why it was done. Traceability should be bi-directional. We use automated release notes generated which contain every detail of change made & also generates charts from Pull Request Meta data. Using version control should be like writing book. We work on new chapters(code changes) without altering the published book(production code). Readers(users) continue enjoying the current version while we develop next

CI pipelines are to be implemented for every Code change. Following Pull Request reviews(in GIT), peers can quickly find issues that might otherwise result in potential bugs. We say, arrest the bugs before it moves to next phase. We integrate with code analysis tool as well. We make the CI to fail based on the code analysis tool quality gate result. CI is like conveyor belt in a factory. Each code change is tested immediately as it moves along the belt. If a product(Code change) is faulty, it's caught & fixed early in the assembly line, preventing defects from reaching the customers.

Create a staging environment that mimics the production setup. Test also with real data wherever possible. Staging environment are like rehearsal for a play. Actors(developers) practice their lines(code changes) on a duplicate stage(staging environment) before actual performance(production). Mistakes are fixed before the show. Compare the performance of old and new code versions with A/B testing. This can gather data to make informed decisions on which version to keep. This is like taste-testing 2 flavors of ice cream. You offer customers(users) a choice between 2 flavors(code versions). You measure which flavor(version) is preferred without disrupting their overall ice cream experience.

One way to ensure the changes did not impact the existing functionality is to keep regression test suite updated at all times and perform regression testing.

Deploy updates gradually to minimize disruptions. Kind of rolling updates. This is like changing tyres of a moving car. Change one tyre at a time, car is not stopped for long time. Always have rollback plan so that in case issue arise after deployment. Example: If the new login system causes errors, roll back to previous version within minutes. Rollback plans are like safety net while tightrope walking. If we loose balance(encounter issues), we can quickly return to previous stable position(code version) to avoid falling(System failure).

One way to get deployment not to disturb your code is to have as many deployments as possible. Carefully consider the updates to reach release and perform regression and performance testing for each release.

Implement robust monitoring tools. setup alerts to notify performance degradation immediately. Example: Receive alert if the response time for the login system exceeds a defined threshold. Monitoring is like having a doctor constantly checking our vital signs. Example: If your heart rate (server/system response time) exceeds a safe threshold, the doctor(alert system) notifies you immediately. This allows timely intervention.

User Communication: Little bit on this also. Inform users about upcoming updates & maintenance. Provide clear instructions & expected downtime. Example: Send a notification to users that the login system will be temporarily unavailable for maintenance at so-and-so time. Informing users about updates is like announcing a brief interval during a movie or watching a TV serial. Viewers(users) know what to expect and with clear instructions, they patiently wait for the movie (system) to resume. While minimizing disruptions to software performance, we have to ensure a smoother user experience and maintain system reliability