OSS: Difference between revisions

From Training Material
Jump to navigation Jump to search
mNo edit summary
mNo edit summary
Line 12: Line 12:
{{Can I use your material}}
{{Can I use your material}}


== Introduction ==
== Introduction/Outline ==
* Code management, versioning, and licensing
* Code management, versioning, and licensing
* Automation and code quality (best practices)
* Automation and code quality (best practices)
Line 52: Line 52:
-->
-->


<!-- VER2
= Modern Software Development Practices (Python & JavaScript) =
---
This training covers best practices for managing, testing, and documenting software projects built with '''Python''' and '''JavaScript'''.


## Slide 1 — Title
== Code Management, Versioning, and Licensing ==
* Use '''Git''' for source control
* Branching strategy:
** ''main'' – stable production code
** feature branches – new development
* Use '''Semantic Versioning''' (MAJOR.MINOR.PATCH)
* Add a '''LICENSE''' file (MIT or Apache 2.0 commonly used)
* Protect main branches with:
** Pull / Merge Request reviews
** Mandatory CI checks


**Modern Software Development Practices**
== Automation and Code Quality (Python & JS) ==
Code, Quality, CI, Testing, and Documentation


---
=== Python ===
* Linters: '''flake8''', '''pylint'''
* Formatter: '''black'''
* Import sorting: '''isort'''
* Type checking: '''mypy'''


## Slide 2 — Code Management, Versioning & Licensing
=== JavaScript ===
* Linter: '''ESLint'''
* Formatter: '''Prettier'''
* Type checking: '''TypeScript''' (recommended)


* Use **Git** for source control
Best practices:
* Adopt a clear branching strategy:
* Run linters and formatters automatically
* Keep functions small and readable
* Follow PEP 8 (Python) and standard JS style guides


  * `main` / `master`, `develop`, feature branches
== Continuous Integration (CI) ==
* Versioning:
CI pipelines automatically validate code on each push or pull request.
 
  * **Semantic Versioning (SemVer)**: `MAJOR.MINOR.PATCH`
* Licensing:
 
  * Always include a `LICENSE` file
  * Common licenses: MIT, Apache 2.0, GPL
* Protect main branches with reviews & CI checks
 
---
 
## Slide 3 — Automation & Code Quality (Best Practices)
 
* Automate repetitive tasks:
 
  * Linting, formatting, builds, tests
* Enforce code quality with:
 
  * Linters (ESLint, Flake8, Pylint)
  * Formatters (Prettier, Black)
* Follow coding standards & style guides
* Keep code small, readable, and well-commented
 
---
 
## Slide 4 — Continuous Integration (CI)
 
**GitHub Actions / GitLab CI**
 
* Automatically run on:
 
  * Pull Requests / Merge Requests
  * Push to main branches
* Typical CI pipeline:
 
  1. Install dependencies
  2. Lint & format check
  3. Run tests
  4. Build artifacts
* Fail fast → catch issues early
 
---
 
## Slide 5 — Automated Testing
 
* **Unit Tests**
 
  * Test small, isolated functions
* **Integration Tests**
 
  * Test interactions between components
* **End-to-End (E2E) Tests**
 
  * Test full user workflows
* Best practices:


  * Tests run automatically in CI
=== Example: GitHub Actions ===
  * Keep tests fast & deterministic
<syntaxhighlight lang="yaml">
  * Measure coverage (but don’t chase 100%)
name: CI


---
on:
  pull_request:
  push:
    branches: [ main ]


## Slide 6 — Changelog & Commit Standards
jobs:
  build:
    runs-on: ubuntu-latest


* Maintain a `CHANGELOG.md`
    steps:
      - uses: actions/checkout@v4


  * Follow **Keep a Changelog**
      - name: Set up Python
  * Sections: Added, Changed, Fixed, Deprecated
        uses: actions/setup-python@v5
* Use **Conventional Commits**
        with:
          python-version: "3.11"


  * `feat:`, `fix:`, `docs:`, `chore:`
      - name: Install Python dependencies
* Benefits:
        run: |
          pip install -r requirements.txt


  * Clear project history
      - name: Lint Python
  * Easier releases & automation
        run: |
          flake8 .
          black --check .


---
      - name: Run Python tests
        run: pytest


## Slide 7 — Issue Management & Roadmap
      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: "20"


* Use issues to track:
      - name: Install JS dependencies
        run: npm ci


  * Bugs, features, tasks, ideas
      - name: Lint JS
* Maintain a roadmap:
        run: npm run lint


  * Short-term vs long-term goals
      - name: Run JS tests
  * Use milestones or project boards
        run: npm test
* Keep issues updated and prioritized
</syntaxhighlight>
* Close issues with references to commits/PRs


---
=== Example: GitLab CI ===
<syntaxhighlight lang="yaml">
stages:
  - lint
  - test


## Slide 8 — Best Practices for Issue Creation
python_lint:
  stage: lint
  image: python:3.11
  script:
    - pip install flake8 black
    - flake8 .
    - black --check .


* Use **issue templates**:
python_test:
  stage: test
  image: python:3.11
  script:
    - pip install -r requirements.txt
    - pytest


   * Bug report
js_lint:
   * Feature request
   stage: lint
* Apply **labels**:
   image: node:20
  script:
    - npm ci
    - npm run lint


  * `bug`, `enhancement`, `documentation`, `priority`
js_test:
* Use **milestones**:
   stage: test
 
   image: node:20
   * Group issues by release/version
   script:
* Write clear titles & descriptions
    - npm ci
* Include steps to reproduce (for bugs)
    - npm test
 
</syntaxhighlight>
---
 
## Slide 9 — Documentation (Why It Matters)
 
* Documentation is part of the product
* Helps:
 
   * New contributors onboard faster
  * Users adopt your software
  * Reduce support questions
* Keep docs:
 
   * Clear, concise, and up-to-date
 
---
 
## Slide 10 — Effective README.md
 
A good README should include:
 
* **Project objectives & overview**
* **Installation instructions**
* **Usage examples**
* **Configuration (if applicable)**
* **Contribution guidelines (brief)**
* **License information**
 
---
 
## Slide 11 — Contributing Guide (CONTRIBUTING.md)
 
* How to:
 
  * Fork & clone the repo
  * Create branches
  * Write commits & tests
* Code style & standards
* Pull Request process
* Expected review workflow
* Code of Conduct (optional but recommended)
 
---
 
## Slide 12 — API Documentation
 
* Keep APIs well documented and discoverable
* Common tools:
 
  * **Swagger / OpenAPI** (REST APIs)
  * **Sphinx** (Python)
  * **Docusaurus** (developer portals)
* Best practices:
 
  * Auto-generate docs from code
  * Include examples & error responses
  * Version your API docs
 
---
 
## Slide 13 — Key Takeaways
 
* Automate everything you can
* Enforce quality with CI & testing
* Keep issues, commits, and changelogs consistent
* Treat documentation as a first-class citizen
* Small discipline upfront → big savings later 🚀
 
---
-->
 
= Modern Software Development Practices =
This training provides an overview of best practices for code management, automation, CI, testing, issue tracking, and documentation.
 
== Code Management, Versioning, and Licensing ==
* Use '''Git''' for source code management
* Adopt a clear branching strategy:
** ''main'' / ''master'' for stable releases
** feature branches for development
* Follow '''Semantic Versioning (SemVer)''' (MAJOR.MINOR.PATCH)
* Always include a '''LICENSE''' file
* Common licenses: MIT, Apache 2.0, GPL
* Protect main branches with code reviews and CI checks
 
== Automation and Code Quality (Best Practices) ==
* Automate repetitive tasks:
** Linting
** Formatting
** Builds
** Tests
* Enforce code quality using:
** Linters (ESLint, Flake8, Pylint)
** Formatters (Prettier, Black)
* Follow consistent coding standards
* Keep code readable, modular, and well-commented
 
== Continuous Integration (CI) ==
'''GitHub Actions''' and '''GitLab CI''' enable automated workflows.
 
Typical CI pipeline:
# Install dependencies
# Run linting and formatting checks
# Execute automated tests
# Build artifacts


Benefits:
Benefits:
* Early detection of issues
* Early detection of issues
* Consistent quality checks
* Enforced quality standards
* Faster feedback for developers
* Reliable and repeatable builds


== Automated Testing ==
== Automated Testing ==
Testing types:
 
* '''Unit Tests'''
=== Python ===
** Test individual functions or components
* Frameworks: '''pytest''', '''unittest'''
* '''Integration Tests'''
* Tools:
** Test interactions between components
** pytest-cov (coverage)
* '''End-to-End (E2E) Tests'''
** requests-mock / responses (API mocking)
** Test complete user workflows
 
=== JavaScript ===
* Unit & integration: '''Jest''', '''Vitest'''
* End-to-end (E2E): '''Cypress''', '''Playwright'''


Best practices:
Best practices:
* Run tests automatically in CI
* Run tests automatically in CI
* Keep tests fast and reliable
* Test behavior, not implementation details
* Track coverage, but prioritize meaningful tests
* Keep test execution fast


== Changelog and Commit Standards ==
== Changelog and Commit Standards ==
* Maintain a '''CHANGELOG.md'''
* Maintain '''CHANGELOG.md'''
* Follow '''Keep a Changelog''' format:
* Follow '''Keep a Changelog''' structure:
** Added
** Added
** Changed
** Changed
** Fixed
** Fixed
** Deprecated
** Deprecated
* Use '''Conventional Commits''' format:
** feat:
** fix:
** docs:
** chore:


Benefits:
=== Conventional Commits ===
* Clear project history
* feat: new feature
* Easier releases
* fix: bug fix
* Improved automation
* docs: documentation
* test: tests
* chore: maintenance


== Issue Management and Roadmap ==
== Issue Management and Roadmap ==
* Use issues to track:
* Use issues to track bugs, features, and technical debt
** Bugs
* Organize work using milestones and boards
** Features
* Reference issues in commits and merge requests
** Tasks
** Technical debt
* Maintain a project roadmap
* Use milestones or project boards
* Reference issues in commits and pull requests


== Best Practices in Issue Creation ==
== Best Practices in Issue Creation ==
* Use '''issue templates''' (bug reports, feature requests)
* Use issue templates (bug / feature)
* Apply '''labels''' (bug, enhancement, documentation, priority)
* Apply labels:
* Group issues with '''milestones'''
** python
* Write clear titles and descriptions
** javascript
* Include steps to reproduce for bugs
** bug
** enhancement
** documentation
* Always include clear reproduction steps for bugs


== Documentation ==
== Documentation ==
Documentation is a core part of the project:
* Improves onboarding
* Reduces support overhead
* Increases adoption and maintainability


=== Effective README ===
=== Effective README ===
A good '''README.md''' should include:
A strong '''README.md''' includes:
* Project objectives and overview
* Project overview
* Installation instructions
* Python / Node.js requirements
* Installation steps
* Usage examples
* Usage examples
* Configuration details
* Testing instructions
* Contribution overview
* License
* License information


=== Contributing Guide (CONTRIBUTING.md) ===
=== Contributing Guide (CONTRIBUTING.md) ===
The contributing guide should describe:
Should define:
* How to fork and clone the repository
* Environment setup
* Branching strategy
* Coding standards
* Commit and testing requirements
* Commit conventions
* Pull request workflow
* Pull Request workflow
* Code review process
* Code of conduct (optional)


== API Documentation ==
== API Documentation ==
API documentation should be clear and up to date.


Common tools:
=== Python ===
* '''Sphinx''' – documentation from docstrings
* '''FastAPI''' – automatic OpenAPI / Swagger
* '''MkDocs''' – lightweight docs
 
=== JavaScript ===
* '''Swagger / OpenAPI''' – REST APIs
* '''Swagger / OpenAPI''' – REST APIs
* '''Sphinx''' – Python projects
* '''JSDoc''' – inline documentation
* '''Docusaurus''' – Developer portals
* '''Docusaurus''' – documentation portals


Best practices:
== Recommended Project Structure ==
* Auto-generate documentation from source code
Example structure for a combined Python + JavaScript repository:
* Provide examples and error responses
 
* Version API documentation
<syntaxhighlight lang="text">
project-root/
├── backend/
│  ├── app/
│  │  ├── __init__.py
│  │  ├── main.py
│  │  ├── api/
│  │  └── services/
│  ├── tests/
│  ├── requirements.txt
│  └── pyproject.toml
├── frontend/
│  ├── src/
│  │  ├── components/
│  │  ├── pages/
│  │  └── services/
│  ├── tests/
│  ├── package.json
│  └── package-lock.json
├── docs/
│  ├── api/
│  └── guides/
├── .github/ or .gitlab/
│  └── ci/
├── CHANGELOG.md
├── CONTRIBUTING.md
├── README.md
└── LICENSE
</syntaxhighlight>


== Key Takeaways ==
== Key Takeaways ==
* Automate wherever possible
* CI enforces quality for Python and JavaScript
* Enforce quality with CI and testing
* Automated testing reduces regressions
* Standardize commits, changelogs, and issues
* Clear structure improves maintainability
* Treat documentation as a first-class citizen
* Documentation is part of the codebase

Revision as of 21:57, 12 February 2026

THIS IS A DRAFT

This text may not be complete.

title
OSS Training Course
author
Lukasz Sokolowski


OSS

OSS Training Materials

Introduction/Outline

  • Code management, versioning, and licensing
  • Automation and code quality (best practices)
  • Continuous Integration (CI) on GitHub/GitLab
  • Automated testing (unit, integration, end-to-end)
  • Changelog (Keep a Changelog, Conventional Commits)
  • Issue management and roadmap
  • Best practices in issue creation (templates, labels, milestones)
  • Documentation
    • Effective README: objectives, installation, usage, contributions
    • Contributing Guide (CONTRIBUTING.md)
    • API documentation (Swagger, Sphinx, Docusaurus, etc.)


Modern Software Development Practices (Python & JavaScript)

This training covers best practices for managing, testing, and documenting software projects built with Python and JavaScript.

Code Management, Versioning, and Licensing

  • Use Git for source control
  • Branching strategy:
    • main – stable production code
    • feature branches – new development
  • Use Semantic Versioning (MAJOR.MINOR.PATCH)
  • Add a LICENSE file (MIT or Apache 2.0 commonly used)
  • Protect main branches with:
    • Pull / Merge Request reviews
    • Mandatory CI checks

Automation and Code Quality (Python & JS)

Python

  • Linters: flake8, pylint
  • Formatter: black
  • Import sorting: isort
  • Type checking: mypy

JavaScript

  • Linter: ESLint
  • Formatter: Prettier
  • Type checking: TypeScript (recommended)

Best practices:

  • Run linters and formatters automatically
  • Keep functions small and readable
  • Follow PEP 8 (Python) and standard JS style guides

Continuous Integration (CI)

CI pipelines automatically validate code on each push or pull request.

Example: GitHub Actions

name: CI

on:
  pull_request:
  push:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.11"

      - name: Install Python dependencies
        run: |
          pip install -r requirements.txt

      - name: Lint Python
        run: |
          flake8 .
          black --check .

      - name: Run Python tests
        run: pytest

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: "20"

      - name: Install JS dependencies
        run: npm ci

      - name: Lint JS
        run: npm run lint

      - name: Run JS tests
        run: npm test

Example: GitLab CI

stages:
  - lint
  - test

python_lint:
  stage: lint
  image: python:3.11
  script:
    - pip install flake8 black
    - flake8 .
    - black --check .

python_test:
  stage: test
  image: python:3.11
  script:
    - pip install -r requirements.txt
    - pytest

js_lint:
  stage: lint
  image: node:20
  script:
    - npm ci
    - npm run lint

js_test:
  stage: test
  image: node:20
  script:
    - npm ci
    - npm test

Benefits:

  • Early detection of issues
  • Enforced quality standards
  • Reliable and repeatable builds

Automated Testing

Python

  • Frameworks: pytest, unittest
  • Tools:
    • pytest-cov (coverage)
    • requests-mock / responses (API mocking)

JavaScript

  • Unit & integration: Jest, Vitest
  • End-to-end (E2E): Cypress, Playwright

Best practices:

  • Run tests automatically in CI
  • Test behavior, not implementation details
  • Keep test execution fast

Changelog and Commit Standards

  • Maintain CHANGELOG.md
  • Follow Keep a Changelog structure:
    • Added
    • Changed
    • Fixed
    • Deprecated

Conventional Commits

  • feat: new feature
  • fix: bug fix
  • docs: documentation
  • test: tests
  • chore: maintenance

Issue Management and Roadmap

  • Use issues to track bugs, features, and technical debt
  • Organize work using milestones and boards
  • Reference issues in commits and merge requests

Best Practices in Issue Creation

  • Use issue templates (bug / feature)
  • Apply labels:
    • python
    • javascript
    • bug
    • enhancement
    • documentation
  • Always include clear reproduction steps for bugs

Documentation

Effective README

A strong README.md includes:

  • Project overview
  • Python / Node.js requirements
  • Installation steps
  • Usage examples
  • Testing instructions
  • License

Contributing Guide (CONTRIBUTING.md)

Should define:

  • Environment setup
  • Coding standards
  • Commit conventions
  • Pull Request workflow

API Documentation

Python

  • Sphinx – documentation from docstrings
  • FastAPI – automatic OpenAPI / Swagger
  • MkDocs – lightweight docs

JavaScript

  • Swagger / OpenAPI – REST APIs
  • JSDoc – inline documentation
  • Docusaurus – documentation portals

Recommended Project Structure

Example structure for a combined Python + JavaScript repository:

project-root/
├── backend/
│   ├── app/
│   │   ├── __init__.py
│   │   ├── main.py
│   │   ├── api/
│   │   └── services/
│   ├── tests/
│   ├── requirements.txt
│   └── pyproject.toml
│
├── frontend/
│   ├── src/
│   │   ├── components/
│   │   ├── pages/
│   │   └── services/
│   ├── tests/
│   ├── package.json
│   └── package-lock.json
│
├── docs/
│   ├── api/
│   └── guides/
│
├── .github/ or .gitlab/
│   └── ci/
│
├── CHANGELOG.md
├── CONTRIBUTING.md
├── README.md
└── LICENSE

Key Takeaways

  • CI enforces quality for Python and JavaScript
  • Automated testing reduces regressions
  • Clear structure improves maintainability
  • Documentation is part of the codebase