{
    "uuid": [
        {
            "value": "22cf1c29-6d70-49ea-87b4-0dd2bcdb9952"
        }
    ],
    "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:53+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": "Overcoming deployment anxiety"
        }
    ],
    "created": [
        {
            "value": "2022-10-12T00:00:00+00:00"
        }
    ],
    "changed": [
        {
            "value": "2025-05-11T09:00:53+00:00"
        }
    ],
    "promote": [
        {
            "value": false
        }
    ],
    "sticky": [
        {
            "value": false
        }
    ],
    "default_langcode": [
        {
            "value": true
        }
    ],
    "revision_translation_affected": [
        {
            "value": true
        }
    ],
    "path": [
        {
            "alias": "\/daily\/2022\/10\/12\/overcoming-deployment-anxiety",
            "langcode": "en"
        }
    ],
    "body": [
        {
            "value": "\n          <p>As a Developer with 15 years of experience, I still sometimes get \"deployment anxiety\" - when I've backed up the database and tagged a release, but even though the CI pipelines are passing and the staging site is working, I'm holding off on pushing the latest code to be released to production - trying to think of any potential issues that could arise from this deployment and avoid any downtime.<\/p>\n\n<p>When I thought about this further, the releases that I've felt anxious or nervous about have usually been in at one or both of the following categories:<\/p>\n\n<ul>\n<li>The release includes a lot of changes, and maybe a combination of different types of changes such as framework or CMS updates, bug fixes, or new features.<\/li>\n<li>It's been a long time, maybe weeks or months, since the last production release.<\/li>\n<\/ul>\n\n<p>The best way to resolve both of these issues, I think, is to break down the large releases into smaller ones, and to deploy them more frequently.<\/p>\n\n<p>In the opposite scenario, the releases where the changes are small and it's been a short time since the previous release - ideally minutes or hours - have been the ones where I've been the least nervous.<\/p>\n\n<p>If a single commit is being released, then I can be confident that if there is a failure, I can either revert it and put things back the way they were or quickly identify the issue and push a fix. This isn't the case for large changes as the potential source of the failure is larger and it will take longer to find and fix.<\/p>\n\n<p>If a bug fix or a feature needs to be reverted, I'm happy knowing that I can do that easily without also reverting the CMS update that was deployed separately - rather than them all being released together.<\/p>\n\n<p>There are other advantages too - clients or product owners are generally happier if the new feature or fix that they requested is on production within hours or days rather than weeks or months, and having your latest code deployed to production rather than on a staging branch makes it a lot easier if you need to deploy an urgent fix or security update.<\/p>\n\n<p>If you're familiar with the DevOps Research and Assessment (DORA) team, three of their key metrics are deployment frequency, lead time for changes, and time to restore service. All of these are improved by small and frequent releases.<\/p>\n\n<p>In my <a href=\"/presentations\/deploying-php-ansible-ansistrano\">Deployments with Ansible and Ansistrano talk<\/a>, I mention that there is a separate rollback role, but I don't think that I've ever used it.<\/p>\n\n<p>Because I'm deploying small changes often, it's usually much easier to fix forward than it is to rollback, and knowing this makes me a lot less anxious when deploying changes.<\/p>\n\n        ",
            "format": "full_html",
            "processed": "\n          <p>As a Developer with 15 years of experience, I still sometimes get \"deployment anxiety\" - when I've backed up the database and tagged a release, but even though the CI pipelines are passing and the staging site is working, I'm holding off on pushing the latest code to be released to production - trying to think of any potential issues that could arise from this deployment and avoid any downtime.<\/p>\n\n<p>When I thought about this further, the releases that I've felt anxious or nervous about have usually been in at one or both of the following categories:<\/p>\n\n<ul>\n<li>The release includes a lot of changes, and maybe a combination of different types of changes such as framework or CMS updates, bug fixes, or new features.<\/li>\n<li>It's been a long time, maybe weeks or months, since the last production release.<\/li>\n<\/ul>\n\n<p>The best way to resolve both of these issues, I think, is to break down the large releases into smaller ones, and to deploy them more frequently.<\/p>\n\n<p>In the opposite scenario, the releases where the changes are small and it's been a short time since the previous release - ideally minutes or hours - have been the ones where I've been the least nervous.<\/p>\n\n<p>If a single commit is being released, then I can be confident that if there is a failure, I can either revert it and put things back the way they were or quickly identify the issue and push a fix. This isn't the case for large changes as the potential source of the failure is larger and it will take longer to find and fix.<\/p>\n\n<p>If a bug fix or a feature needs to be reverted, I'm happy knowing that I can do that easily without also reverting the CMS update that was deployed separately - rather than them all being released together.<\/p>\n\n<p>There are other advantages too - clients or product owners are generally happier if the new feature or fix that they requested is on production within hours or days rather than weeks or months, and having your latest code deployed to production rather than on a staging branch makes it a lot easier if you need to deploy an urgent fix or security update.<\/p>\n\n<p>If you're familiar with the DevOps Research and Assessment (DORA) team, three of their key metrics are deployment frequency, lead time for changes, and time to restore service. All of these are improved by small and frequent releases.<\/p>\n\n<p>In my <a href=\"/presentations\/deploying-php-ansible-ansistrano\">Deployments with Ansible and Ansistrano talk<\/a>, I mention that there is a separate rollback role, but I don't think that I've ever used it.<\/p>\n\n<p>Because I'm deploying small changes often, it's usually much easier to fix forward than it is to rollback, and knowing this makes me a lot less anxious when deploying changes.<\/p>\n\n        ",
            "summary": null
        }
    ],
    "feeds_item": [
        {
            "imported": "1970-01-01T00:33:45+00:00",
            "guid": null,
            "hash": "31f3de322f3c108fbaf235ca30453bf5",
            "target_type": "feeds_feed",
            "target_uuid": "90c85284-7ca8-4074-9178-97ff8384fe76"
        }
    ]
}