Changing code

When you want to develop and share code changes with others, here is what you would usually need to do to avoid messing up things for you or the team. I assume you use git source control here, but the advice may apply to other tools too. I highlighted the items that are often forgotten but are very important using red and orange foreground color:

A. Actual development

  1. Prepare :
    • Plan: select the tasks to do, checking their parent user stories, features, and/or epics to gather information about the expected work output (requirements).
      • Update work items: set status values for the selected tasks and their parent user stories, features and/or epics to in progress.
  2. Develop:
    • Update code: change the main code as needed to resolve the requirements associated to the selected tasks and user stories.
      • If you need to interrupt work to resolve other work items in the meantime follow these steps.
      • Ensure quality: check code analysis output, update and run unit tests, and optionally also integration and other automatic test flows; if you have warnings, errors and/or tests do not pass, correct code to resolve the issues.
      • Update work items: periodically add/update information regarding the time you used in the development for the associated task.

B. Sharing changes

  1. Prepare:
    • Link work items: make a reference from the commit you are preparing at least to the associated user story in the work plan; optionally you can also link the related child task and/or parent feature/epic/etc. to easily find changes later.
    • Commit: Pack up your changes locally on the dev branch.
  2. Merge:
    • Fetch: see if others already made other code changes in parallel (while you were doing yours).
      • Pull: if there are any fetched changes, merge them into your code.
        • Resolve conflicts: if it’s not done automatically, you’ll need to resolve conflicts manually, and commit them too.
  3. Submit:
    • Push: upload your changes (and the merge, if it was needed) to the server, such as into the dev remote branch, so others could see and use it.
      • Check: ensure that continuous build integration, if configured on the remote branch, succeeds; if they are any build errors (such as if the build is configured differently than on your local machine), resolve them locally with high priority and resubmit (later, also update your local build configuration to reflect the continuous integration one).
        • Update work items: update information regarding the time you used to complete the development for the associated task and set status values for the associated work items to done.
  4. Release:
    • Cherry pick: if needed, cherry pick only some changes from dev branch into a separate dev-complete branch, and then push the branch to the server to be able to pull request them separately towards the master code.
      • Pull request: create a pull request from the dev or dev-completed branch to the master branch, that might be configured to automatically release changes to your production environment once the request is approved.