methodology/methodology-development.md

4 KiB

Development

  • Development Cycle Agile

Development Infrastructure

  • Setup Dev Machine
  • Setup Environments
    • You should be able to run the code and develop without a dedicated server. Get virtualized with docker-compose.
    • Deploy using Docker + Docker-Compose. Docker keeps all your application events separate from OS events.
      • Add to .bashrc on remote server (remove or replace ENV.):
      • alias doco="docker-compose -f docker-compose.ENV.yml"; cd /opt/project/
  • Setup Version Control
  • Documentation
    • Your repo should have a one-liner for isntallation andd running: (docker-compose.yml + doco up)

Python Developement

Develop with Version Control

# Git Log A DOG acronym
git log --all --decorate --oneline --graph

# when you have uncommitted changes
git add --patch <pattern>

# check what you've staged
git diff --cached

# NEW DEVELOPMENT FLOW
# clone repo with local_name enables several clones
git clone <repo> <local_name>

# optional: checkout (i.e switch to) a branch to continue developing from there
git checkout <feature/featurename>

# optional if you switched branch on the last step
# switched branch: branch out from
git checkout <feature/newfeature>
git branch <feature/newfeature>
git push --set-upstream origin <feature/newfeature>

# delete branch locally (-d: normal, -D: force)
git branch -D <branch_name_1> <branch_name_2> <branch_name_1>
# delete remote
git push origin -d <branch_name>

# Comparing / Merging two branches
git merge --no-commit --no-ff <feature/otherfeaturebranch>

# get file from another branch
git checkout <otherbranch> -- path/to/dir

# delete branches not present on remote
git remote prune origin

# see all commits that affected somefile
git log --follow -- filename

# search code in all history
git log -S "some_old_varname" --oneline --all

Submitting multiple PRs

Context:

  1. submit PR for feature1
  2. from feature1 branch make new branch feature2
  3. commit and push feature2 changes
  4. submit PR
  5. Both PRs approved
# there should be one or more flows that account for cases where:
# -> feature1 gets change requests
# -> feature1 is rejected and made obsolete