All Projects → priceloop → conventions

priceloop / conventions

Licence: other
∞ Priceloop Engineering Conventions for Scala, Python, Git Workflow etc

Projects that are alternatives of or similar to conventions

awesome-practical-posts
I sum up the articles of tech blogs and share that.
Stars: ✭ 64 (-36%)
Mutual labels:  engineering
DragonArmor
Dragon Armor 3D-printable CAD files (Autodesk Fusion 360)
Stars: ✭ 46 (-54%)
Mutual labels:  engineering
cs-sakaryauniversity
Sakarya Üniversitesi'nde okuduğum süre boyunca karşıma çıkan tüm ödevler, ders notları ve çıkmış sınav soruları (All the assignments, lecture notes and exams)
Stars: ✭ 133 (+33%)
Mutual labels:  engineering
mllint
`mllint` is a command-line utility to evaluate the technical quality of Python Machine Learning (ML) projects by means of static analysis of the project's repository.
Stars: ✭ 67 (-33%)
Mutual labels:  engineering
devon4flutter-non-bloc-arch
A guide aiming to bridge the gap between the absolute Flutter basics and clean, structured Flutter Development
Stars: ✭ 283 (+183%)
Mutual labels:  conventions
node-red-contrib-FIWARE official
FIWARE-Node-Red integration supporting NGSI-LD
Stars: ✭ 14 (-86%)
Mutual labels:  engineering
career-ladders
A sample of career ladders I use for my organization, open sourced for anyone.
Stars: ✭ 676 (+576%)
Mutual labels:  engineering
docs-product
OutSystems 11 product documentation
Stars: ✭ 32 (-68%)
Mutual labels:  engineering
UliEngineering
A python library for calculations perfomed in electronics engineering
Stars: ✭ 35 (-65%)
Mutual labels:  engineering
socrata-py
socrata data-pipeline python library
Stars: ✭ 55 (-45%)
Mutual labels:  engineering
Tensor
A library and extension that provides objects for scientific computing in PHP.
Stars: ✭ 146 (+46%)
Mutual labels:  engineering
Apex-Code-Conventions
Apex conventions and best practices for Salesforce Developers
Stars: ✭ 28 (-72%)
Mutual labels:  conventions
outsystems-ui-kit
No description or website provided.
Stars: ✭ 25 (-75%)
Mutual labels:  engineering
Performance-Engineers-DevOps
This repository helps performance testers and engineers who wants to dive into DevOps and SRE world.
Stars: ✭ 35 (-65%)
Mutual labels:  engineering
redd.one
Software engineering blog.
Stars: ✭ 31 (-69%)
Mutual labels:  engineering
soda-swift
SODA SDK for Apple's Swift programming language
Stars: ✭ 42 (-58%)
Mutual labels:  engineering
microhomie
MicroPython implementation of the Homie MQTT convention for IoT.
Stars: ✭ 72 (-28%)
Mutual labels:  conventions
College-Notes
Contribute your handwritten PDF notes and help other students ✌ #DecodersCommunity 🖤
Stars: ✭ 30 (-70%)
Mutual labels:  engineering
engineering-management
A list of resources about Software Engineering Management
Stars: ✭ 31 (-69%)
Mutual labels:  engineering
ElectricalEngineering.jl
Julia electrical engineering package
Stars: ✭ 22 (-78%)
Mutual labels:  engineering

👩‍💻 Conventions

Our Priceloop Engineering conventions for Scala, Python, Git Workflow etc.

📖 Contents

Scala Styling Guide

We use Scalafmt to format our code. Use the following config in your projects:

version = 3.3.1

runner.dialect                  = scala213source3
style                           = defaultWithAlign
maxColumn                       = 120
includeCurlyBraceInSelectChains = false
danglingParentheses.preset      = true
lineEndings                     = preserve
trailingCommas                  = always

continuationIndent {
  callSite = 2
  defnSite = 2
}

newlines {
  penalizeSingleSelectMultiArgList = false
  alwaysBeforeElseAfterCurlyIf     = true
}

project {
  git = true
  excludeFilters = [
    target/
  ]
}

binPack {
  parentConstructors = true
}

rewrite {
  rules = [RedundantParens, SortImports, PreferCurlyFors]
}

align {
  preset                   = most
  arrowEnumeratorGenerator = true
  tokens."+"               = [":=", "+=", "++="]
  openParenCallSite        = false
}

Python Styling Guide

Use the following pre-commit hooks:

  • isort
  • pylint following Google styling guide
  • black formater with the following flags:
    • -l 110 -S -t
    • VSCode settings.json
"python.formatting.blackArgs": ["-l", "110", "-S", "-t"]
  • flake8

  • docstrings: Google conventions

  • Quotes: double

  • mypy

  • Use pre-commit with the following hooks:

repos:
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v2.2.3
    hooks:
      - id: trailing-whitespace
      - id: end-of-file-fixer
      - id: debug-statements
      - id: requirements-txt-fixer
      - id: flake8

  - repo: https://github.com/pre-commit/mirrors-mypy
    rev: v0.720
    hooks:
      - id: mypy
        args: [--allow-redefinition, --ignore-missing-imports]

  - repo: local
    hooks:
      - id: isort
        name: "Sort imports"
        language: system
        types: [file, python]
        entry: isort
      - id: pylint
        name: "PyLint"
        language: system
        types: [file, python]
        files: .
        exclude: test_*.py
        entry: python3 -m pylint
      - id: black
        name: "Black"
        language: system
        pass_filenames: false
        entry: black .
        args: [--safe, --quiet, "--line-length=110", "--skip-string-normalization"]

Naming Conventions

Git Branch Naming

Your branch name should follow the format type-scope.

Types:

  • feat
  • fix
  • chore

Storage buckets, i.e. s3, gcs

ai.priceloop.{{bucket_purpose}}.{{environment}}

e.g. ai.priceloop.data.prod

{{environment}} = {prod, stage}

{{bucket_purpose}} can potentially be broken down to

{{layer}}.{{bucket_purpose}}, e.g.

ai.priceloop.ml.metadata
ai.priceloop.frontend.assets
ai.priceloop.dataplatform.metadata

Namespace

  • Long: priceloop-production / priceloop-staging

  • Short: priceloop-prod / priceloop-stage

Git Commit Structure

  • In general, follow the Conventional Commit guidelines
  • Be descriptive
  • Use all lower-case
  • Limit punctuations (no dots, no commas)
  • Short (under 70 characters is best)

👉 Follow the git commit structure for commits that are getting merged. In branches, when you do something temporary (e.g. testing ideas etc), you don't need to follow it

Git Branch Flow

We follow the following PRs flow with user facing feature(s):

develop → { git checkout -b } → feature branch → {PR} develop → {PR} master

CI/CD

We use Github Actions as the CI solution. Every repository with the codebase for user facing features must contain the following CI configuration/workflow definition files:

.github
└── workflows
    ├── develop.yaml
    ├── master.yaml
    └── pr_branches_check.yaml

Where

  • develop.yaml - defines the CI pipeline to deploy to the stage env
  • master.yaml - defines the CI pipeline to deploy to the prod env
  • pr_branches_check.yaml - defines the check to validate if PR is compliant with the branch flow

pr_branches_check.yaml

name: PR Branches Check

on:
  pull_request:
    types:
      - opened
      - reopened

jobs:
  develop_to_master:
    if: github.base_ref == 'master'
    runs-on: ubuntu-latest
    steps:
      - name: Check if PR to "master" is from "develop"
        if: ${{ github.head_ref != 'develop' }}
        run: |
          echo "Wrong source branch, only develop->master PR's allowed"
          exit 1
  any_to_develop:
    if: github.base_ref == 'develop'
    runs-on: ubuntu-latest
    steps:
      - name: Check if PR is to "develop"
        if: ${{ github.head_ref == 'refs/heads/master' }}
        run: |
          echo "Wrong source branch, only "!master"->develop PR's allowed"
          exit 1

GitHub Branches Protection Rules

Every Github repository containing user facing features must have the protection rules for the master and develop branches.

Secrets

⚠️ Never put any username, password on Git, always use local environments or secrets manager to access services

  • Metadata considered as secrets:
    • AWS keys (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY)
    • Access tokens (any oauth2 tokens which have long life time)
    • Access credentials, i.e. combination of password and user name
    • Webhook URLs
  • Metadata which can be stored to git:
    • Bucket name, path to object
    • Database name
    • Resource ID, URI ← it may be a subject of change/dispute

Note: in case of doubt whether the info is a secret/internal or can be public, treat it at a higher security level, i.e. as a secret. It costs nothing to downgrade security level, but it's quite expensive to upgrade it 😃

How to share secrets

To share between peers:

  • Please use gpg to encrypt opaque text secret.
  • Slack DM is acceptable, but remember to delete the secret message after it was received!

We use AWS Secret Manager and github secrets for secrets to be used programmatically.

Language

  • Stick to American English e.g. optimize instead of optimise or behavior instead of behaviour. In doubt check Google 😃

License

  • For private repos, no License necessary
  • For public repos, we should use Apache 2.0 License
Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].