77 lines
2.8 KiB
YAML
77 lines
2.8 KiB
YAML
|
uuid:
|
||
|
|
- value: c58749a0-bec2-415b-aa25-33eca5cce8b7
|
||
|
|
langcode:
|
||
|
|
- value: en
|
||
|
|
type:
|
||
|
|
- target_id: daily_email
|
||
|
|
target_type: node_type
|
||
|
|
target_uuid: 8bde1f2f-eef9-4f2d-ae9c-96921f8193d7
|
||
|
|
revision_timestamp:
|
||
|
|
- value: '2025-05-11T09:00:16+00:00'
|
||
|
|
revision_uid:
|
||
|
|
- target_type: user
|
||
|
|
target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849
|
||
|
|
revision_log: { }
|
||
|
|
status:
|
||
|
|
- value: true
|
||
|
|
uid:
|
||
|
|
- target_type: user
|
||
|
|
target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849
|
||
|
|
title:
|
||
|
|
- value: 'Releasing a new project one page at a time'
|
||
|
|
created:
|
||
|
|
- value: '2024-04-02T00:00:00+00:00'
|
||
|
|
changed:
|
||
|
|
- value: '2025-05-11T09:00:16+00:00'
|
||
|
|
promote:
|
||
|
|
- value: false
|
||
|
|
sticky:
|
||
|
|
- value: false
|
||
|
|
default_langcode:
|
||
|
|
- value: true
|
||
|
|
revision_translation_affected:
|
||
|
|
- value: true
|
||
|
|
path:
|
||
|
|
- alias: /daily/2024/04/02/releasing-a-new-project-one-page-at-a-time
|
||
|
|
langcode: en
|
||
|
|
body:
|
||
|
|
- value: |
|
||
|
|
<p>How do you release a new project?</p>
|
||
|
|
|
||
|
|
<p>Do you build everything and release everything at once?</p>
|
||
|
|
|
||
|
|
<p>I've used the strategy of building and releasing it a page at a time and running two versions simultaneously.</p>
|
||
|
|
|
||
|
|
<p>The main live version stays running, and you use a tool like NGINX or Cloudflare as a gatekeeper to direct traffic to the correct application - either the current one or the new one - based on the requested page.</p>
|
||
|
|
|
||
|
|
<p>When a page is ready, you add it to the list of pages to serve from the new application to put it live.</p>
|
||
|
|
|
||
|
|
<p>If there's an issue, it is also easy to revert to the original page.</p>
|
||
|
|
|
||
|
|
<p>I've used this approach with my website and for client Drupal upgrade projects, where some pages are on Drupal 7 and some on Drupal 10.</p>
|
||
|
|
|
||
|
|
<p>It's not the right approach for every situation, but it's a useful one to have in the toolkit.</p>
|
||
|
|
|
||
|
|
|
||
|
|
format: full_html
|
||
|
|
processed: |
|
||
|
|
<p>How do you release a new project?</p>
|
||
|
|
|
||
|
|
<p>Do you build everything and release everything at once?</p>
|
||
|
|
|
||
|
|
<p>I've used the strategy of building and releasing it a page at a time and running two versions simultaneously.</p>
|
||
|
|
|
||
|
|
<p>The main live version stays running, and you use a tool like NGINX or Cloudflare as a gatekeeper to direct traffic to the correct application - either the current one or the new one - based on the requested page.</p>
|
||
|
|
|
||
|
|
<p>When a page is ready, you add it to the list of pages to serve from the new application to put it live.</p>
|
||
|
|
|
||
|
|
<p>If there's an issue, it is also easy to revert to the original page.</p>
|
||
|
|
|
||
|
|
<p>I've used this approach with my website and for client Drupal upgrade projects, where some pages are on Drupal 7 and some on Drupal 10.</p>
|
||
|
|
|
||
|
|
<p>It's not the right approach for every situation, but it's a useful one to have in the toolkit.</p>
|
||
|
|
|
||
|
|
|
||
|
|
summary: null
|
||
|
|
field_daily_email_cta: { }
|