92 lines
3.4 KiB
YAML
92 lines
3.4 KiB
YAML
uuid:
|
|
- value: b9297a41-9a9a-46e4-a7a9-4281ff5c88e7
|
|
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:24+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: 'Decide, automate, document'
|
|
created:
|
|
- value: '2023-12-29T00:00:00+00:00'
|
|
changed:
|
|
- value: '2025-05-11T09:00:24+00:00'
|
|
promote:
|
|
- value: false
|
|
sticky:
|
|
- value: false
|
|
default_langcode:
|
|
- value: true
|
|
revision_translation_affected:
|
|
- value: true
|
|
path:
|
|
- alias: /daily/2023/12/29/decide-automate-document
|
|
langcode: en
|
|
body:
|
|
- value: |
|
|
<p>Decide, automate, document</p>
|
|
|
|
<p>Here are three steps to making decisions, such as introducing new tools and processes:</p>
|
|
|
|
<p>Decide.</p>
|
|
|
|
<p>Automate.</p>
|
|
|
|
<p>Document.</p>
|
|
|
|
<p>First of all, a decision needs to be made about what you will introduce.</p>
|
|
|
|
<p>It could be whether to write automated tests, use static analysis, choose which coding standard to use, or make architecture decisions about how you want to build your application.</p>
|
|
|
|
<p>Once you've decided and added the tool or process, automate it if you can.</p>
|
|
|
|
<p>A CI pipeline or Git Hooks can run tests and checks automatically to know if the code complies with what was agreed upon rather than relying on this being done manually.</p>
|
|
|
|
<p>Finally, document it so that it's available for others to read and reference, including new team members.</p>
|
|
|
|
<p>Ensure to document why this was added, what problem it solves, any alternatives that were considered and any side effects or consequences. Technical design documents and ADRs (architectural decision records) are great for this!</p>
|
|
|
|
<p>In the future, you may want to revisit the decision and decide if it's still correct, and you'll appreciate having the information documented.</p>
|
|
|
|
|
|
format: full_html
|
|
processed: |
|
|
<p>Decide, automate, document</p>
|
|
|
|
<p>Here are three steps to making decisions, such as introducing new tools and processes:</p>
|
|
|
|
<p>Decide.</p>
|
|
|
|
<p>Automate.</p>
|
|
|
|
<p>Document.</p>
|
|
|
|
<p>First of all, a decision needs to be made about what you will introduce.</p>
|
|
|
|
<p>It could be whether to write automated tests, use static analysis, choose which coding standard to use, or make architecture decisions about how you want to build your application.</p>
|
|
|
|
<p>Once you've decided and added the tool or process, automate it if you can.</p>
|
|
|
|
<p>A CI pipeline or Git Hooks can run tests and checks automatically to know if the code complies with what was agreed upon rather than relying on this being done manually.</p>
|
|
|
|
<p>Finally, document it so that it's available for others to read and reference, including new team members.</p>
|
|
|
|
<p>Ensure to document why this was added, what problem it solves, any alternatives that were considered and any side effects or consequences. Technical design documents and ADRs (architectural decision records) are great for this!</p>
|
|
|
|
<p>In the future, you may want to revisit the decision and decide if it's still correct, and you'll appreciate having the information documented.</p>
|
|
|
|
|
|
summary: null
|
|
field_daily_email_cta: { }
|