Skip to content

Development Guidelines

These Development Guidelines provide guidance to Power Partners employees and team members. It is an overview of how we do things.

Best Practices

  1. We commit and push at least every evening

  2. We report time every evening

  3. We make sure that our tasks are up-to-date before every meeting (daily standup, demo, planning)

  4. We tick off AC's (Acceptance Criteria) whenever achieved

  5. We reference each commit with the respective planio tasks by using refs #123 or closes #123 (NO COMMIT WITHOUT REFS OR CLOSES)

Organization

  1. We use scrum (Power Partners flavor)

  2. We use weekly sprints

  3. We have a demo/retrospective on Friday, and a Planning on Monday

  4. We have daily standup meetings

Tools

  1. We use planio to

    1. manage sprints: Agile board
    2. store security aspects: Wiki
    3. source code repository: git (linked to GitHub)
    4. clients: 1 planio projects per client
    5. manage projects: category
    6. estimation: on the planio tasks
    7. time reporting: time reporting
    8. help desk functionality

  2. We use GitHub for our git repository (and we link to them from within planio)

  3. We use Teams to

    1. communicate. Use the Client Project on the pwrp tenant when a thread is clearly attributable to a client. Use a private channel if the client has access to the team

  4. We use Markdown and Mermaid for solution design and documentation of projects and libraries. We love Markdown. It even works in the planio git browser. For example, see planio example.

  5. We use Python for API downloads

  6. We use VSC (Visual Studio Code) for software development and for git

  7. We use GitHub Client for git (in addition to VSC)

  8. We use Azure Storage Explorer to review Storage Accounts

  9. We use Azure Data Studio to explore databases

  10. We use Parquet Viewer to inspect Parquet files Parquet Viewer on GitHub

Tech Stack

  1. We use Power BI for visualization

  2. We use Power Query / M for data wrangling, unless we have a DWH (Data Factory)

  3. We use Azure Data Factory (ADF) for a DWH, using the following components

    1. Azure Functions / python for API downloads
    2. Blob storage for storage of files (without Azure Datalake 2, because that will not allow us to configure version history, which is important for support cases)
    3. Azure Copy activity for copying and simple wrangling
    4. Azure Data Flow from complex wrangling
    5. Under investigation: Use SQLServer with DTU costing instead of files

  4. We use parquet files wherever possible (and not, say, CSVs)

  5. We use SQLServer (instead of parquet) whenever we can get incremental updates from the source (e.g. a REST API where we can filter for last_update). SQLServer then lets us update records selectively, which is a pain in files.

Coding Conventions

Azure

  1. We use a single Storage Account and a single Blob Container for a solution

  2. We also use a single azure function app containing all the azure functions

Python

Naming Conventions

  1. Packages (folders) should have short names. The typical package is pwrp\pck_name, e.g. pwrp\bouwsoft

  2. Modules (files) should have short, all-lowercase names. Underscores can be used in the module name if it improves readability. Python packages should also have short, all-lowercase names, although the use of underscores is discouraged.

  3. Class names should normally use the CamelCase convention.

  4. Function and (local) variable names should be lowercase, with words separated by underscores as necessary to improve readability

Terminology

  1. implement: write code

  2. deploy: roll out/install (e.g. the extension, the azure function, the pipeline)

  3. upgrade: deploy to a newer version (as opposed to re-deploy the same same version, e.g. in case of a faulty deployment)

  4. refresh: download latest data (e.g. run pipeline, refresh dataset)

  5. update: let's not use this, it's too generic, it could mean any of the above

Version Control

  1. We use git on GitHub

  2. We use one git repository per client

  3. The name of the git repository is equal to the client short code, e.g. cgk

  4. We link all check-ins to a planio task by using refs #123 in the check-in comment

  5. We use branches sparingly, namely only if

    1. we have a long-running dev task
    2. which might conflict with someone else's work
    3. we never use a branch for work on the pbix file

  6. We use GitHub lfs (GitHub Large File Storage) to store pbix files and other large files, such as csv, XLSX, pbix, JPG, PNG

Time Reporting

  1. All time spent on Delivery tasks is logged to planio.

  2. If you don't have a planio issue, create one or raise it with the Project Manager

  3. Always log to the Task, Question, or Meeting. Never log to the Order.

  4. Add a comment to your time log. It will make things easier in case a client challenges a time report

  5. Always log time as Billable, except if instructed otherwise by the Project Manager

For details, see terminology-and-concepts .