ОбзорДокументацияВойти
/
aleksandr.globa
/
projects_management_system
Код
Запросы
0
Задачи
0
Вики
Пакеты
0
Релизы
0
CI/CD
Аналитика
Безопасность

projects_management_system

0

Описание

Projects Management System

117 KiB
README
В избранном0
Форки0

Языки

  • Shell99,4%
  • Makefile0,6%
1
2
0
release
год назад
scripts
год назад
README.md
год назад
open_license_ru
год назад
README.md

🛠 Projects Management System

This repository provides the orchestration layer for managing versioned releases, DevOps automation, and modular tooling — built to scale across multiple projects.
It starts with

freelance-aggregator-api
as the first integrated example.

The system is built around a layered, script-first architecture using pure Bash and UNIX tools, emphasizing reproducibility, testability, and modularity.

📦 Each release is self-contained inside the

release/
folder, fully versioned and isolated for traceability (e.g.,
v.2/
). “Bash Script Template Framework” for
script_template.sh
 in minimal configuration (LLM-assistent refactoring)

🗂️ Contents

⏳ TODO

  • Add the guide for the "LLM-assistent refactoring" based on
    script_template.sh
     with minimal configuration.
  • Develop
    modifier.sh
     to automate changes inside scripts
  • Design and expand test functionality
  • Add GitHub-Rendered Diagram
  • Finalize
    make release-pipeline
     command
  • Handle multiple projects per
    v.X
     release
  • Refine per-project
    .env
     overrides

🧭 Philosophy

The system is built around a simple idea: make every release repeatable, traceable, and modular — without hiding behind opaque tooling.
Bash and standard tools keep it lightweight, transparent, and easy to debug as projects scale.

Every pipeline step is script-first, dry-run safe, and explicitly scoped via

.env
files.
Sharp separation between working and published sources, isolated version folders, and clear function-level logging are central principles.

🔹 Composable building blocks over monolithic flows: every action can be tested, run, and debugged independently.

🧱 Design Principles

  • ✅ CI/CD ready: pure shell and Makefile commands, no extra dependencies.
  • 🔄 Repeatable releases: artifacts are versioned, traceable, and dry-run safe.
  • 📖 Clear documentation: includes workflow guides and file maps.
  • 🧪 Self-testing flows: per-version test scripts (
    tests.sh
    ).
  • 🧠 Scriptable everything: simulate or trigger full releases manually, no CI lock-in.

🔁 All scripts default to

DRY_RUN=true
.
Real changes only happen when explicitly set to
DRY_RUN=false
.

Each version (

v.1
,
v.2
, etc.) maintains its own scripts, docs, and Makefile under the
release/
 directory, ensuring every project stays cleanly isolated and reproducible across time.

🔥 Features Overview

  • 🧱 Versioned release pipelines (isolated per
    v.X/
     folder)
  • 📁 Working and published sources for curated projects (parallel synced trees)
  • ⚙️ Dynamic
    .env
     configurations     (global, scripts layer, local project scope)
  • 🛠 Script-first automation (bash-native steps)
  • 🧪 Dry-run mode by default
  • 🔍 Full traceability (logs, dry-runs, bash tracing)
  • 🚀 GitHub Release integration
  • 🔄 Composable steps (bump, publish, tag separately)
  • 🧩 Makefile CLI wrappers (
    make bump
    ,
    make publish
    )
  • 🧹 Minimal dependencies (Bash, Git, UNIX tools only)

🧩 Architecture Overview

The system is built around a layered release structure, where each versioned folder (

v.1/
,
v.2/
, etc.) acts as a self-contained engine.

Built for:

  • Isolation: per-version reproducibility
  • Traceability: version-specific logs, tags, dry-runs
  • Extensibility: easily add projects or pipelines

📁 Folder Structure

PathPurpose
release/
Root of all versioned releases (e.g.,
v.1/
,
v.2/
), each fully isolated.
release/v.2/
Active release folder: contains scripts, Makefile, docs, and curated project code.
release/v.2/scripts/
Modular bash scripts: versioning, publishing, changelog management, and GitHub releases.
release/v.2/docs/
Backstage documentation: workflow guides, file references, contribution conventions.
release/v.2/freelance-aggregator-api/
Curated project folder — contains working and published code trees.

⚙️ Core Components

ComponentRole
runner.sh
High-level runner: release pipelines internally. Useful for local dry-run, tests and CI debug sessions.
launcher.sh
Backstage controller: actually performs the release actions. Respects flags like
DRY_RUN
,
FORCE_TAG
, etc.
Makefile
CLI façade: exposes all internal steps as simple
make
 commands (
make bump
,
make publish
,
make tag
).

🛡️ Separation of concerns:

runner.sh
do orchestration →
launcher.sh
 executes tasks →
Makefile
 wraps them for easy usage.

📦 Project Structure (inside a Release)

Each curated project inside a release has:

FolderPurpose
*-work/
Editable development source.
*-pub/
Published clean copy, synced during release process.

Synced during release via

publish.sh
.

⚙️ Configuration (
.env
 Scopes)

📌 Quick Visual Legend:

  • runner.sh
     → Global
    .env
     file
  • launcher.sh
    ,
    scripts/
     → Scripts layer
    .env
    's
  • Per-project folders → Local project
    .env

🧠 Notes on the
.env
 Scopes (explained):

ScopePathPurpose
Global scope
./.env
Sets general environment variables for the whole system (e.g.,
DRY_RUN
,
PROJECT_NAME
, base
RELEASE
 path).
Scripts layer
./release/v.X/.env
 and/or
scripts/.env
 (optional)		Every script (
*.sh
) sources these
.env
 files dynamically to configure behavior.
Local project scope
release/v.X/$PROJECT_NAME/.env
Defines project-specific settings like
WORKING_VERSION_DIR
,
PUBLISHED_VERSION_DIR
, etc.

🛠️ How to Use

For the PMS itself

StepCommandPurpose
0
add_versioning.sh
Bootstrap versioning
1
./add_to_changelog.sh "some change"
Add under
[Unreleased]
.
2(normal coding/commits)Daily work.
3Ready to release? →
./bump_version.sh patch
Move Unreleased changes into a new version section + bump VERSION file.
4
git add ./CHANGELOG.md ./VERSION
Stage the changes.
5
git commit -m "release: version X.Y.Z"
Commit release bump.
6
git tag -s vX.Y.Z -m "Release X.Y.Z"
Create Git tag (signed if possible).
7
git push origin main --tags
Push changes and tags upstream.
8
github_release.sh

For curated project

  1. Clone
  2. Edit or stage your project inside the
    *-work/
     folder.
  3. Use Makefile commands:
    • make bump
       — bump SemVer and update changelog.
    • make publish
       — sync and prepare the publish copy.
    • make tag
       — commit and tag release.

📢 Always check

.env
settings before running.

📈 Roadmap

Near-term improvements planned:

  • 🧪 Strengthen built-in test scripts (
    tests.sh
    ) with CI-ready checks
  • 🚀 Explore matrix release testing for multiple Python versions or project templates
  • ✅ Add full
    make release-pipeline
     command (wraps full flow)
  • ✅ Improve GitHub Release automation (attach zipped artifacts)
  • 🧩 Add pluggable pre-publish and post-publish hooks
  • 📚 Expand per-project contribution docs