After successfully running DSC in production for all this time, you sit back amazed that all the work you have been doing is addictive. You haven't had to undo work you've previously done to get something new automated, and you can handle the most insane list of requirements life can dish out with ease.

Of course, it wasn't always easy and might have required some extra thought or preparation. It might have required changing how you approached things to something more aligned with the configuration management processes you read in the beginning of the book. DSC didn't have a DSC resource built in for every piece of software in your environment or every task you needed to accomplish, but we can say that for any CM product on the market. The point of any CM is not to provide a way to do everything but to provide a way to do most things, along with a way for you to do the rest that's unique to your environment. From reading this book, you know how to create DSC resources to handle your special cases.

Things are, in fact, going so well that something was bound to come up and ruin your parade. The application team has come to you to tell you that they have finished working on the next major version of the Apollo application. This is great news as it will mean a faster application that can handle more load with fewer nodes than before. You start thinking of the one line you need to update in order to change the version installed in your environment but are interrupted by the application team. They admit that you can't update the environment all at once; you will have to do it in batches and some servers will need to remain on the old version for customers that have not upgraded their systems yet.

This is a quandary at first; how are you going to install software only on some of the target nodes and not others? You start thinking about making a custom DSC resource that detects software versions on a target node and then checks a file for a list of servers that need to be updated. Then, you start planning to manually remove servers from your beautiful DSC setup while secretly crying inside. Happily, you remember the first chapters of this book explaining and praising the benefit of splitting the configuration data from the execution script and have an epiphany when you realize you've already done half the work when you made your ConfigurationData hash. Each individual Node hash overrides the information provided in the wildcard Node block (the one with *). All you have to do is specify the older version number on the servers for them to keep the older version:

    @{
      AllNodes = @(
        @{
          NodeName        = 'app01'
          ConfigurationId = 'ab2c2cb2-67a3-444c-bc55-cc2ee70e3d0c'
          Roles           = @('appserver')
          Apollo = @{
            Name               = 'Apollo'
            ProductId          = '{e70c4829-91dc-4f0e-a404-4eba81f6feb9}'
            SourcePath         = 'http://build.pantheon.net/apollo/packages/releases/apollo.1.1.0.msi'
            Arguments          = ''
            ConfigFilePath     = "$env:ProgramFilesApolloconfigapp.config"
            ConfigFileContents = "importantsetting=`$true"
          }
        },
        @{
          NodeName        = 'app02'
          ConfigurationId = '8e8f44e6-aaac-4060-b072-c9ae780ee5f7'
          Roles           = @('appserver')
        },
        @{
          NodeName        = 'app03'
          ConfigurationId = 'c880da2b-1438-4554-8c96-0e89d2f009c4'
          Roles           = @('appserver')
        },
        @{
          NodeName        = 'web01'
          ConfigurationId = 'b808fb65-5b16-4f83-84c6-aa398a6abdd5'
          Roles           = @('webserver')
        },
        @{
          NodeName        = 'web02'
          ConfigurationId = '2173f5d7-7343-4a16-a8a8-5188f2d1cdb0'
          Roles           = @('webserver')
        },
        @{
          NodeName             = '*'
          RefreshMode          = 'Pull'
          ConfigurationMode    = 'ApplyAndAutoCorrect'
          PSDSCCPullServer     = 'https://dsc01:8080/PSDSCPullServer.svc'
          AllowModuleOverwrite = $true
          RebootNodeIfNeeded   = $true
          Apollo   = @{
            Name               = 'Apollo'
            ProductId          = '{e70c4829-91dc-4f0e-a404-4eba81f6feb9}'
            SourcePath         = 'http://build.pantheon.net/apollo/packages/releases/apollo.2.0.0.msi'
            Arguments          = ''
            ConfigFilePath     = "$env:ProgramFilesApolloconfigapp.config"
            ConfigFileContents = "importantsetting=`$true"
          }
          Aurora = @{
            SourcePath         = 'http://build.pantheon.net/aurora/releases/aurora.zip'
            DestinationPath    = "$env:SystemDriveinetpubwwwaurora"
            WebApplicationName = 'Aurora'
            WebSiteName        = 'Aurora'
            WebAppPoolName     = 'AuroraAppPool'
          }
        }
      )
    }  

Things have gotten quite cozy among the engineering teams as the concepts and practices of DevOps and continuous integration have started to really become ingrained in the company. Teams have started moving to more agile processes, adopting sprints, and producing more frequent releases. You're still in charge of systems, but the day-to-day information entry is now done by the teams initiating the changes. Bringing them down to the system configuration level has opened their eyes to the pain points of the configuration and maintenance of their applications, and they have fast-tracked updating the installation process of the Aurora website in order to enable a simpler and faster deployment process.

The increased releases didn't add any extra workload for you, as the ConfigurationData hash you have kept up to date all by yourself has now been added to the version control system all the teams use. Updating versions and configuration data has become part of the release process, which is now auditable from development to deployment. Teams can see how the products have changed over time and how different releases have either increased or decreased in configuration complexity.