5. Development

Responsible: TC
Responsibility: Coding, Push to test DB, Record what you've done,
Next Stage: Code Review Objective: Fulfilling requirement of client through implementation.

General

Most part of this stage is completing the development and try to keep it within the estimated time. Priority is on quality.

Pre-coding

Adapt your environment by fetching the User's Production DB since that will be the DB you merge your code to. Use Support Tool to fetch/restore databases and use it for your test environment.

Coding

For SH, checkout from production branch as {version_no}-{task_id}-{trigram}.
For Saas, checkout from company's branch as {version_no}-{company_name}-{trigram} if exist. Else, checkout from main to create branch {version_no}-{company_name} first.

Constantly test out your developments by installing it on the fetched database. Keep track of what you've added as development as proof that you did something according to their requirement. Use Joplin for note taking. Share this document with FC to let them understand what you did in the development.

Suggestion: do git commits consistently so that if anything goes wrong you can revert/compare to commit. Do commits in small bits or for every accomplishment your dev did. Everytime you commit, take notes at the same time.

Pushing to Test DB

Once your code has fulfilled the requirements, push it to test DB. For Saas, zip your module -> Go to test DB link (debug mode) -> Apps -> Import Module For SH, push development to staging as intstructed by FC.

Before pushing to test DB, squash multiple commits of the same module together so that you can remember module names easily.

git rebase -i HEAD~<num> # choose the first one and use fixup on the rest

After

To ensure code is clean and give the best possible performance, have it to go through code review

Using Git (Recommendation)

This is simply a recommendation and not a standard workflow. This is only meant to help you organize your developments.
For every development you are doing, always prepare 2 branches:

1. Push Branch: One branch holds only one commit. This branch is the one that should be used for pushing to database and for review. SHould be in remote repo.
2. Dev Branch: One branch is for development purposes. Keep all commits here and any changes done here is adapted to main branch. Not necessary to be pushed to remote repo.

In Branch 1, keep commits to only one by squashing/rebasing commits together. Whenever there is any dev updated or added on branch 2, cherry-pick it and squash again. VSCode's GitLens provides a good interface to do this.