At Haptik, our focus is always on delivering quality products to our clients, and to achieve this, we have established a robust software development life cycle (SDLC) process. This blog will take you through our entire feature development process, which comprises of five high-level phases.
We follow Agile-Dev Ops development and release practices that are equipped with all the best practices to ensure efficient delivery of our products. The first phase of our SDLC is planning, where we identify the project requirements, scope, and deliverables. This is followed by the architecture review and developer documentation phase, where we define the overall system architecture and provide detailed documentation for developers to follow.
In the feature development phase, we develop and iterate until the feature meets our high-quality standards. We prioritize continuous feedback and collaboration to ensure that the feature aligns with the client's vision. The next phase is security, integration, and release versioning/notes, where we perform thorough testing, integration, and versioning to ensure that the feature is stable and secure.
Our final phase is the revisit phase, where we analyze user feedback and implement necessary improvements to the product. As we grew and matured as a company, we implemented a proper change and configuration management process to support ISO 27001:2013 and facilitate better production issue management. This process is defined separately and is responsible for making changes/releases to the production environment.
In conclusion, our SDLC process is designed to ensure that we consistently deliver quality products to our clients. We follow industry best practices and implement the necessary technical controls to make our development and release process efficient and secure. At Haptik, we are committed to delivering world-class products that meet our clients' needs and exceed their expectations.
Let's get into phase by phase.
Plan Phase
The Plan phase is the first and critical step in our software development life cycle (SDLC). The product owner and engineers collaborate to gather all requirements around a feature in a document called the Product Requirements Document (PRD). The product team usually initiates this process, and the engineering managers then take over. The PRD has three key parts, and it provides a comprehensive understanding of what the product should do while avoiding defining how it should do it.
The PRD workflow has several stages, starting with product managers building the PRDs as per the templates on Notion. Each version of the PRD is versioned, and the version changes are documented in the PRD. Once a PRD version is ready, product managers fill out the operational checklist to identify all relevant stakeholders.
To obtain approval, the Product Manager must raise a JIRA ticket on the Document Review JIRA board, and the JIRA ticket will be assigned to the Engineering Lead and Product Lead as approvers. The JIRA ticket will contain sections such as a link to the PRD on Notion, a PDF of the PRD version for approval, the impact on each stakeholder, a brief description of the impact, and a risk analysis from the Infosec perspective.
In summary, the Plan phase has three key parts, including the PRD document, backlog grooming/kick-off meeting, and change request process. The PRD document is a crucial aspect of our SDLC, and it provides a detailed understanding of what a product should do. The PRD workflow ensures that all stakeholders are identified and the necessary approvals obtained before proceeding to the next phase of the SDLC.
Architecture Review & Developer Docs
Owner: Architecture / Developer / Engineering Manager
In this phase, we review the technical aspects of the feature development and ensure that the product is being built correctly and efficiently. There are four key parts to this:
Developer Docs/Tech Docs:
We create a new technical document that contains all the technical details related to the feature. This document must include specifics about which parts of the older code are being touched, dependencies, and how the feature will impact other teams. This document serves as the architecture/security review document.
Architecture Review:
We review the feature to ensure that it is scalable and built with the future in mind. We check to make sure that it does not break any existing system logic and does not affect or overload any existing live feature. We also evaluate the deployment plan to ensure that it can scale for all users across all setups. Other key considerations include database queries and performance, use of external and internal microservices, and monitoring/logging.
Security Review:
We follow a thorough security review to ensure that the feature has been designed with user data privacy and security in mind. We evaluate where the feature will be hosted, how user data will be stored, and if it will be exposed to the internet. We also consider OWASP guidelines, external services, feature public exposure, HTTP methods, and any further security testing that may be required.
JIRA Tickets:
We create JIRA tickets for the feature/bug and add story points and owners. These tickets are an important part of our development process and help us keep track of progress and ensure accountability.
By following this comprehensive architecture review and developer documentation process, we ensure that all our products are built with quality, scalability, and security in mind.
Feature Development & Testing:
Owner: Product/Platform/Implementation Teams
Development activities:
- Follow GitFlow and Commit Template for version control and easy review process.
- Push code to GitHub, raise a PR, and run test cases in the CI pipeline.
- Achieve at least 80% test coverage and avoid reducing overall code coverage.
- Prepare a deployment checklist to reduce dependency on developers.
- Conduct development environment testing and aim for 80% test coverage.
- Push code to pre-staging/integration environment for integration testing.
QA sign-off:
- QA testing starts on pre-staging environment and includes manual and automated test cases.
- Once all test cases pass, QA provides written sign-off or transition ticket on JIRA.
CVEs/SAST check:
- CI checks for CVEs against PR and sends an email if any are found.
- Check for CVEs for any new package added and fix for any older package encountered.
- SAST checks using SonarCloud
Note: The feature development phase concludes with the code being in develop.
Security, Pre-production & Release Versioning/Notes
Owner: Engineering Manager/Developer/Product/InfoSec
Security Testing: We conduct high level manual and automation testing to identify and fix application vulnerabilities. Use Web Penetration suite to test the specific PR. Some testing for security would be done in DEV environment as well
Pre-production Release: We follow GitFlow Model and ask if everyone's changes are good to go into release. Once CR ticket is ready, push the code to Preprod/UAT. Monitor the system for errors and review the application's normal functionalities.
Release Versioning/Notes/Docs: Automated release notes are generated and shared internally with the engineering and product teams for each release. Prepare release notes for the feature to be sent out to all platform users/clients if required. We publish the release version for the platform tool/component and update the docs.
Code Release & Change Management Flow: Create a Release to Master Pull Request, which automatically creates a release version/tag and sends out an email with all changes. Check the change management policy at Haptik and create a CM ticket to note Change Risk & Plan of Action if necessary.
Release Monitoring: We follow the SOPs/steps listed in our release doc to monitor all the systems and graphs post-release to ensure nothing is breaking.
And it’s done! However, the most important part is after the code goes live in production.
To ensure an improved SAAS product with best quality, the following things should be monitored and reviewed post go-live:
- Feature Usage: Check if the feature is being used as intended by the users.
- Error Resolution: Check if any errors have been reported and resolve them promptly.
- Stats Collection: Collect and analyze performance stats and APM/Infra data to identify any potential issues and optimize the product accordingly.
In addition to the above, a regular feedback cycle should be established to keep improving the product based on user feedback.
Conclusion
Haptik’s SDLC process is robust, clearly-defined and designed for maximum efficiency. Each phase of the process is geared towards building a world-class product that is high-quality, scalable and secure. We follow industry best practices, but our job doesn’t end with the release of the product; we undertake ongoing measures based on user feedback and technological developments to keep the product running smoothly while offering the best user experience possible.
