PIPELINE-3359: Improve repository structure

.flake8

@@ -0,0 +1,7 @@
+[flake8]
+max-line-length = 99
+exclude =
+    .venv
+    .git
+    build
+

.github/workflows/main.yml

@@ -0,0 +1,79 @@
+name: main
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+
+jobs:
+  flake8:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v3
+
+      - name: Set up Python
+        uses: actions/setup-python@v4.1.0
+        with:
+          python-version: 3.8
+
+      - name: Install flake8
+        run: pip --disable-pip-version-check install flake8
+
+      - name: Lint with flake8
+        run: flake8 --count
+
+  tests:
+    name: Python ${{ matrix.python-version }} on ${{ matrix.os }}
+    runs-on: ${{ matrix.os }}
+    strategy:
+      fail-fast: true
+      matrix:
+        os: ["ubuntu-latest"]
+        python-version: ["3.8"]
+    env:
+      VENV: .venv
+      PACKAGE: pipe_encounters
+
+    steps:
+      - uses: actions/checkout@v4
+      - name: Set up Python ${{ matrix.python-version }}
+        uses: actions/setup-python@v4
+        with:
+          python-version: ${{ matrix.python-version }}
+          cache: 'pip'
+          # cache option make the step fail if you don´t have requirements.txt or pyproject.toml on root.
+          # https://github.com/actions/setup-python/issues/807.
+
+      - name: Create virtual environment
+        run: python -m venv $VENV
+
+      - name: Install package with test dependencies
+        run: |
+          . $VENV/bin/activate
+          make install-test
+          pip install .
+
+      - name: Test with pytest
+        run: |
+          . $VENV/bin/activate
+          pytest --cov=$PACKAGE --cov-report=xml
+
+      - name: Upload coverage reports to Codecov
+        if: github.ref == 'refs/heads/main' && matrix.python-version == '3.8'
+        uses: codecov/codecov-action@v4.0.1
+        with:
+          token: ${{ secrets.CODECOV_TOKEN }}
+
+  tests-in-docker:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - name: Set up Python
+        uses: actions/setup-python@v4.1.0
+
+      - name: Build docker image
+        run: make docker-build
+
+      - name: Run tests
+        run: make docker-ci-test

.gitignore

@@ -113,4 +113,6 @@ venv.bak/
 output/
 
 # Pycharm
-.idea
+.idea
+
+.pytest_cache

Dockerfile

@@ -0,0 +1,67 @@
+# ---------------------------------------------------------------------------------------
+# BASE IMAGE
+# ---------------------------------------------------------------------------------------
+FROM python:3.8-slim-bookworm AS base
+
+# Setup a volume for configuration and authtentication.
+VOLUME ["/root/.config"]
+
+# Update system and install build tools. Remove unneeded stuff afterwards.
+# Upgrade PIP.
+# Create working directory.
+RUN apt-get update && \
+    apt-get install -y --no-install-recommends gcc g++ build-essential && \
+    rm -rf /var/lib/apt/lists/* && \
+    pip install --upgrade pip && \
+    mkdir -p /opt/project
+
+# Set working directory.
+WORKDIR /opt/project
+
+# ---------------------------------------------------------------------------------------
+# DEPENDENCIES IMAGE (installed project dependencies)
+# ---------------------------------------------------------------------------------------
+# We do this first so when we modify code while development, this layer is reused
+# from cache and only the layer installing the package executes again.
+FROM base AS deps
+COPY requirements.txt .
+RUN pip install -r requirements.txt
+
+# ---------------------------------------------------------------------------------------
+# Apache Beam integration IMAGE
+# ---------------------------------------------------------------------------------------
+FROM deps AS beam
+# Copy files from official SDK image, including script/dependencies.
+# IMPORTANT: This version must match the one in requirements.txt
+COPY --from=apache/beam_python3.8_sdk:2.49.0 /opt/apache/beam /opt/apache/beam
+
+# Set the entrypoint to Apache Beam SDK launcher.
+ENTRYPOINT ["/opt/apache/beam/boot"]
+
+# ---------------------------------------------------------------------------------------
+# PRODUCTION IMAGE
+# ---------------------------------------------------------------------------------------
+FROM beam AS prod
+
+COPY . /opt/project
+RUN pip install . && \
+    rm -rf /root/.cache/pip && \
+    rm -rf /opt/project/*
+
+# ---------------------------------------------------------------------------------------
+# DEVELOPMENT IMAGE (editable install and development tools)
+# ---------------------------------------------------------------------------------------
+FROM beam AS dev
+
+COPY . /opt/project
+RUN pip install -e .[lint,dev,build]
+
+# ---------------------------------------------------------------------------------------
+# TEST IMAGE (This checks that package is properly installed in prod image)
+# ---------------------------------------------------------------------------------------
+FROM prod AS test
+
+COPY ./tests /opt/project/tests
+COPY ./requirements-test.txt /opt/project/
+
+RUN pip install -r requirements-test.txt

GITHUB-FLOW.md

@@ -0,0 +1,67 @@
+# GitHub Flow
+
+[GitHub Flow]: https://githubflow.github.io/
+
+<div align="justify">
+
+[GitHub Flow] is an ideal workflow for teams that deploy frequently
+and want to iterate quickly without the overhead of long release cycles or complex branching strategies.
+It keeps the process simple and fast,
+enabling continuous integration and deployment,
+which helps catch issues early and deliver features to users rapidly.
+
+These are the basic rules of the workflow:
+1. **`main` is always deployable**
+
+  The `main` branch must be stable and ready to deploy at all times. Never push untested or broken code.
+
+2. **Create descriptively named branches from `main`**
+
+  Start every new feature, fix, or idea in a new branch based on `main`, with clear and meaningful names.
+
+3. **Push to your branch often**
+
+  Push work regularly to the remote to back it up, share progress, and trigger CI.
+
+4. **Open a Pull Request early**
+
+  Use pull requests for code review, discussion, or help—long before the branch is “done.”
+
+5. **Get reviewed and approved before merging**
+
+  Don’t merge until someone reviews and approves your work (even with just a 👍 or `:shipit:`).
+
+6. **Deploy right after merging to `main`**
+
+  Once merged, deploy immediately or soon—everything in `main` should be safe and shippable.
+
+---
+
+This flow emphasizes **simplicity, speed, and collaboration**, especially for teams that deploy frequently.
+
+### Additional team conventions
+
+- If you plan to make a release immediately after merging,
+  bump the version directly in your feature branch.
+  This avoids the need to create a separate release branch just for the version bump.
+
+- Always rebase feature branches on top of `main` before merging them.
+  This, combined with enforcing **merge commits** in GitHub repository settings,
+  results in a semi-linear history on the `main` branch,
+  which is very helpful when using `git log`.[^1]
+  If **merge commits** are not enforced,
+  Git will perform a **fast-forward merge** after rebasing,
+  creating a linear history
+  and losing the context of the feature branch.
+  If merging locally, avoid fast-forward merges with:
+  ```shell
+  git checkout main
+  git pull
+  git merge branch_name --no-ff
+  ```
+
+[^1]: When performing a rebase, it's acceptable to `push --force` to your own feature branch,
+      but **never** on shared branches.
+      Protect `main` and/or `develop` from force pushes via GitHub settings.  
+
+</div>