Do and Don'ts for a Developer

Modified on Fri, 16 Aug at 3:52 PM

ü Do’s	× Don’ts
When a Ticket is assigned to the developer, make sure that the requirement is clear, if not assign it back to custom success team to get the clear requirement.	Do not work on enhancements or bug fixes without clear requirements.
When a ticket is assigned to a developer, it's important for the developer to update its status from open to 'in progress' or another appropriate status as they work on the ticket.
Pull the latest code and create a new branch specifically for each functionality, feature, enhancement or a bug fix. Name these branches descriptively, such as feature/working-branch or bugfix/issue-number.	Avoid pushing changes directly to the main branch. Do not leave debug statements, commented-out code, or console prints in the codebase. Clean up such artifacts before committing changes.
Before merging, schedule a code review to check the code quality.	Avoid skipping or ignoring code reviews.
For monthly releases or periodic bug fixes, raise a PR for each specific change via the appropriate branch. Ensure each build is associated with only one pull request (PR).	Avoid merging multiple PRs simultaneously to staging or production to minimize deployment risks
Always merge code from the pre-production environment to the production environment.	Avoid merging changes directly to the staging and production environments.
Ensure that ZapScale code is enabled only in the production environment.	Do not enable ZapScale code in the local environment, even if you are working directly in the production environment.