77 lines
3.9 KiB
YAML
77 lines
3.9 KiB
YAML
uuid:
|
|
- value: cbc726a3-93f3-41e2-ba6b-9c591096eda9
|
|
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:36+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: |
|
|
Commit often, deploy often
|
|
created:
|
|
- value: '2023-07-30T00:00:00+00:00'
|
|
changed:
|
|
- value: '2025-05-11T09:00:36+00:00'
|
|
promote:
|
|
- value: false
|
|
sticky:
|
|
- value: false
|
|
default_langcode:
|
|
- value: true
|
|
revision_translation_affected:
|
|
- value: true
|
|
path:
|
|
- alias: /daily/2023/07/30/commit-often-deploy-often
|
|
langcode: en
|
|
body:
|
|
- value: |
|
|
<p>This is a follow-up to Friday's email on generic commit messages.</p>
|
|
|
|
<p>In it, I discussed seeing commit messages like <code>Week 20 development</code> in project codebases and why you should write specific commit messages for each change.</p>
|
|
|
|
<p>The other thing is, if you only commit once a week, you can only deploy once a week.</p>
|
|
|
|
<p>That's assuming that, on this project, the changes were committed and pushed weekly. It could have been fortnightly, monthly, or longer.</p>
|
|
|
|
<p>As well as increasing the time between deployments, it also makes them larger and riskier as they include more changes.That commit changed 106 files, added 3,453 lines and removed 17 lines, including custom module and theme changes, contrib module updates and library updates.</p>
|
|
|
|
<p>If the dependencies were committed and deployed first, followed by a series of small custom module and theme changes, even though it would have resulted in more deployments, each one would have been smaller and less risky as there were fewer changes and easier to debug any issues and fail forward.</p>
|
|
|
|
<p>I recommend that everyone commits and pushes their changes at least daily and use trunk-based development so everyone's changes apply and work together and are not separated on feature branches.</p>
|
|
|
|
<p>I recommend that they're pushed live daily, too, or as often as possible - reducing the chance of errors and getting the changes providing value for customers and clients.</p>
|
|
|
|
|
|
format: full_html
|
|
processed: |
|
|
<p>This is a follow-up to Friday's email on generic commit messages.</p>
|
|
|
|
<p>In it, I discussed seeing commit messages like <code>Week 20 development</code> in project codebases and why you should write specific commit messages for each change.</p>
|
|
|
|
<p>The other thing is, if you only commit once a week, you can only deploy once a week.</p>
|
|
|
|
<p>That's assuming that, on this project, the changes were committed and pushed weekly. It could have been fortnightly, monthly, or longer.</p>
|
|
|
|
<p>As well as increasing the time between deployments, it also makes them larger and riskier as they include more changes.That commit changed 106 files, added 3,453 lines and removed 17 lines, including custom module and theme changes, contrib module updates and library updates.</p>
|
|
|
|
<p>If the dependencies were committed and deployed first, followed by a series of small custom module and theme changes, even though it would have resulted in more deployments, each one would have been smaller and less risky as there were fewer changes and easier to debug any issues and fail forward.</p>
|
|
|
|
<p>I recommend that everyone commits and pushes their changes at least daily and use trunk-based development so everyone's changes apply and work together and are not separated on feature branches.</p>
|
|
|
|
<p>I recommend that they're pushed live daily, too, or as often as possible - reducing the chance of errors and getting the changes providing value for customers and clients.</p>
|
|
|
|
|
|
summary: null
|
|
field_daily_email_cta: { }
|