Development leadership
Code review and releases in a Bitrix development team
A minimum process from a clear task to a verified release: context, review, acceptance, rollback and handover.
Code review is more useful when connected to the original task and verification of its outcome. Reading a diff alone does not establish whether the user's need was understood correctly or whether the change can be released safely.
Below is a recommended minimum process for a team maintaining existing enterprise web systems. It can be adopted gradually, starting with one project or type of task.
Before development: make the outcome observable
A task needs a user scenario, expected change and acceptance criterion. Expand “improve the integration” into the error that occurs, how to reproduce it and the expected result after the fix.
The person setting priorities and the person accepting the result may differ. Clarify this in advance. Developers should not have to guess which urgent request takes precedence each time.
If the solution depends on unknown platform behaviour, first define a small investigation. It should answer a specific question so that the team can estimate implementation.
Keep changes reviewable
Combining a bug fix, extensive formatting and a redesign of adjacent architecture makes review difficult. Limit the change to one clear goal and include only necessary related work.
A useful merge request description explains:
- Which problem the change solves.
- What now happens for the user.
- Which components and data are affected.
- How the result was verified.
- What release and rollback require.
This saves time for the next developer investigating the solution months later. Keep the task link, but it does not replace a concise explanation in the change itself.
What to check in review
| Question | Problem it helps reveal |
|---|---|
| Does the behaviour match the task? | A technically correct solution to the wrong problem |
| Are permissions checked on the server? | Direct-request access bypassing the interface |
| What happens on retries and errors? | Duplicates, partial execution and data loss |
| Which platform dependencies are used? | Fragile coupling to a specific version |
| Can the change be verified and released separately? | Hidden release dependencies |
| Will another developer understand it? | Context loss during maintenance handover |
Comments should explain consequences. “This can repeat an external call after a timeout” is more useful than requesting a rewrite without explaining why. Distinguish style preferences from behavioural errors.
Review, testing and acceptance complement each other
The reviewer reads the solution and asks questions. Checks demonstrate behaviour under selected conditions. The task owner confirms that the outcome meets the need. None of these steps fully covers the others.
A small change may need only a few verifiable scenarios. Permissions, data exchange and storage changes need failure checks and checks of related functionality. Verification depth should match the risk.
For Bitrix, record the versions of affected modules. A successful check on another portal with different versions does not prove compatibility with the target environment.
Release and feedback
Before release, identify the person responsible, the action sequence and a short outcome check. If data is affected, rollback must account for its state as well as the old files.
After release, show what changed: behaviour to the process owner, and settings and diagnostics to the maintaining specialist. Feedback may uncover a missing part of the original scenario rather than a code defect.
Tie “done” to an agreed state. For example: code accepted, checks completed, change released and outcome confirmed. If these stages occur at different times, make that visible in the task.
What a team lead can do
Start with one clear agreement: every significant change includes its purpose, verification evidence and release instructions. Then examine the team's actual difficulties and refine the process.
Closed-task counts and review-comment counts alone do not measure quality. Discuss which commitments were met, what blocks results and where the team lacks context or authority.
Documentation
GitLab merge requests support collaborative discussion, review and links to checks. The team's rules must be defined separately; having a tool does not establish a process automatically.