Software Development and Change Management Policy
This policy sets out how we build, review, test, release and change software, for our own products and for clients. The aim is simple: every change is intentional, reviewed, tested, traceable, and can be rolled back.
Document
Policy number
TSS-IT-10
Version
1.0
Effective from
1 September 2026
Next review
March 2027
Owner
IT Team
Approved by
Board of Directors
Applies to
Every employee, trainee and intern, and all source code, infrastructure code, configuration and database changes, and all changes to production systems, for TSS products and for client work.
Issued by
Thakur Systems & Structures Private Limited, CIN U62011PN2026PTC254650
Related policies
Information Security Policy (TSS-IT-02), Password and Authentication Policy (TSS-IT-03), Access Control Policy (TSS-IT-11), Cloud and App Use Policy (TSS-IT-07), Data Privacy and Management Policy (TSS-IT-04)
1. SOURCE CONTROL
All code and configuration lives in the company’s approved code hosting, in repositories the company owns. No company code in personal repositories or accounts.
The main branch is protected: no direct pushes and no force pushes. Every change goes through a pull request.
Work on short-lived branches named for the task, for example feature/login-otp or fix/invoice-rounding.
Write commit messages that say what changed and why, and link to the ticket.
Secrets never go into repositories (Password and Authentication Policy). Secret scanning and dependency scanning are switched on.
2. CODE REVIEW
Every pull request needs at least one approval from another developer before it is merged. Where nobody else is working on the project, the tech lead or a Director reviews it. Changes to security, sign-in, payments or infrastructure need a review from the tech lead or a senior developer.
Reviewers check that the code works, is readable, has tests, handles errors, follows security basics (input validation, access checks, no secrets, safe database queries), and matches the ticket.
Keep pull requests small enough to review properly. Split large changes.
Nobody approves their own pull request.
3. AI-ASSISTED DEVELOPMENT
We expect developers to use AI coding tools. The rules:
Use only approved AI tools (Cloud and App Use Policy), and never put secrets, credentials, personal data or production data into them.
Follow each client’s rules about AI tools for their code.
You are responsible for everything you commit. Read and understand AI-generated code before committing it, and do not commit code you cannot explain.
AI-generated code goes through the same review and testing as any other code. Pay extra attention to security, to licensing (code that looks copied from a known project), to libraries or functions that do not actually exist, and to outdated patterns.
Say in the pull request when a significant part of it was AI-generated, so that the reviewer knows.
4. TESTING
New features and bug fixes come with automated tests where that is reasonable. A bug fix includes a test that would have caught the bug.
The automated tests, code-style checks and security scans run on every pull request. A pull request cannot be merged while they are failing.
Changes are tested before release in a staging environment that matches production as closely as possible.
Test data is made up or anonymised. Never use real personal data or client production data for testing without the client’s written approval (Data Privacy and Management Policy).
5. ENVIRONMENTS
Development, staging and production are kept separate, with separate credentials.
Developers do not have standing access to production. Production access is granted for a specific task and period, and logged (Access Control Policy).
6. TYPES OF CHANGE
| TYPE | WHAT IT IS | APPROVAL NEEDED |
|---|---|---|
| Standard | Routine, low-risk changes of a pre-approved kind, such as content updates or minor dependency patches that pass all checks | Pull request review |
| Normal | Any other change to production | Pull request review, plus release approval from the tech lead or project lead |
| Emergency | An urgent fix for a production outage or a security problem | The tech lead or a Director can approve it verbally; the full review and paperwork follow within one working day |
7. RELEASES
Every release has release notes: what changed, who approved it, and how to roll it back.
Database changes use versioned migration scripts, tested in staging, with a backup taken before they run in production.
Releases happen during working hours, early enough in the day to watch the result and fix any problem. Never in the evening, on a Sunday or on a holiday, and avoid Saturday afternoons. Emergency fixes are made during working hours too. If a client system fails outside working hours, a Director decides what happens next; developers are not called in to work.
After a release, check that the system is healthy: logs, key user flows and monitoring. If something is wrong, roll back first and investigate afterwards.
For client systems, follow the client’s own change and approval process where they have one.
8. DEPENDENCIES AND OPEN SOURCE
Use well-maintained libraries from official sources.
Check that each library’s licence fits the project. Ask the tech lead before using a library with a copyleft licence, such as GPL or AGPL, in client work.
Keep dependencies up to date: critical security updates within 7 days, and others at least monthly.
9. SECURE CODING
Follow the basics from the OWASP Top 10: validate input, use parameterised queries, check authorisation on every request, encode output, protect sessions,
log security events without logging secrets or personal data, and handle errors without exposing internal details. Developers complete secure coding training every year (Employee Training and Awareness Policy).
10. DOCUMENTATION
Every project has a README that explains how to set it up, run the tests and deploy it. Record important design decisions, and anything a new developer would need to know.