docs: clarify standard ci cd model
This commit is contained in:
@@ -366,6 +366,16 @@ make backup-verify BACKUP_DIR=backups/backup_YYYYmmdd_HHMMSS</code></pre>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<div class="box">
|
||||
<h3>What is good enough today vs what is standard later</h3>
|
||||
<ul>
|
||||
<li><strong>Today:</strong> GitHub runs CI, then a LAN-connected Mac deploys to the private test server with the helper scripts.</li>
|
||||
<li><strong>Standard later:</strong> GitHub runs CI, then an approved deploy job promotes tested code to staging and production automatically.</li>
|
||||
<li><strong>Why they differ:</strong> the current test server is inside the LAN, so GitHub-hosted runners cannot reach it directly.</li>
|
||||
<li><strong>When to upgrade:</strong> do it once staging or production lives on a public host, or once you add a self-hosted runner inside the LAN.</li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<div class="box">
|
||||
<h3>Why deploy is manual right now</h3>
|
||||
<p>The test server is inside the local network and uses a private IP address <code>192.168.2.55</code>. GitHub-hosted runners on the public internet cannot reliably reach that target. Because of that, the correct deployment path today is:</p>
|
||||
@@ -377,6 +387,34 @@ make backup-verify BACKUP_DIR=backups/backup_YYYYmmdd_HHMMSS</code></pre>
|
||||
<p>Automatic CD from GitHub becomes appropriate only after moving to a public server or using a self-hosted runner inside the LAN.</p>
|
||||
</div>
|
||||
|
||||
<div class="box">
|
||||
<h3>Recommended standard CI/CD model</h3>
|
||||
<ol>
|
||||
<li>Keep one private repository.</li>
|
||||
<li>Use short-lived feature branches from <code>develop</code>.</li>
|
||||
<li>Require CI to pass before merge into <code>develop</code>.</li>
|
||||
<li>Deploy <code>develop</code> to a staging environment.</li>
|
||||
<li>Promote <code>develop</code> into <code>main</code> only after staging validation.</li>
|
||||
<li>Deploy <code>main</code> to production behind HTTPS with <code>DEBUG=0</code>.</li>
|
||||
<li>Protect production with GitHub environment approvals, production secrets, and rollback steps.</li>
|
||||
</ol>
|
||||
<p>If you want the most standard shape, the long-term target is:</p>
|
||||
<pre><code>feature branch -> CI -> develop -> staging deploy -> validate -> main -> production deploy</code></pre>
|
||||
</div>
|
||||
|
||||
<div class="box">
|
||||
<h3>What to change when this becomes a standard deployment</h3>
|
||||
<ol>
|
||||
<li>Move staging and production onto hosts that GitHub or a self-hosted runner can reach reliably.</li>
|
||||
<li>Keep separate env files and secrets for staging and production.</li>
|
||||
<li>Run production with <code>DJANGO_DEBUG=0</code>, secure cookies, and HTTPS only.</li>
|
||||
<li>Add GitHub environment protection rules for <code>development</code> and <code>production</code>.</li>
|
||||
<li>Use the production deploy path only from <code>main</code>.</li>
|
||||
<li>Add backup verification and health verification as standard post-deploy checks.</li>
|
||||
<li>Later, consider image-based deploys if you want cleaner rollbacks than source-upload deploys.</li>
|
||||
</ol>
|
||||
</div>
|
||||
|
||||
<div class="box">
|
||||
<h3>What to do for normal work</h3>
|
||||
<ol>
|
||||
@@ -391,6 +429,15 @@ make backup-verify BACKUP_DIR=backups/backup_YYYYmmdd_HHMMSS</code></pre>
|
||||
</ol>
|
||||
</div>
|
||||
|
||||
<div class="box">
|
||||
<h3>Decision guide</h3>
|
||||
<ul>
|
||||
<li><strong>Keep the current manual Mac deploy flow</strong> if the server stays private inside the LAN.</li>
|
||||
<li><strong>Use a self-hosted GitHub runner</strong> if you want automated deploys but the server must stay private.</li>
|
||||
<li><strong>Use GitHub-hosted deploy jobs</strong> once staging or production runs on a publicly reachable host or VPN-reachable target.</li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<div class="box">
|
||||
<h3>One-command test deployment</h3>
|
||||
<p>From the Mac on the same network:</p>
|
||||
@@ -448,6 +495,17 @@ make backup-verify BACKUP_DIR=backups/backup_YYYYmmdd_HHMMSS</code></pre>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<div class="box">
|
||||
<h3>Minimal standard checklist for later</h3>
|
||||
<ul>
|
||||
<li>Staging and production must not share secrets.</li>
|
||||
<li>Production deploy must run from <code>main</code> only.</li>
|
||||
<li>Production must have HTTPS, health checks, backups, and a documented rollback path.</li>
|
||||
<li>Runtime config sync must stay explicit. Code deploys should not silently overwrite DB-backed config.</li>
|
||||
<li>Every deploy path should end with a health check and a quick browser verification of critical flows.</li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<div class="box">
|
||||
<h3>If the local deploy helper fails</h3>
|
||||
<ol>
|
||||
|
||||
Reference in New Issue
Block a user