I hope this helps. Great if you want to run with this.

What would need to be done exactly? I am very familiar with PS but never wrote a DSC module before.

Suggest adding public commands that

evaluate the correct SQL Server instance build version
evaluate the build version of an update package.

Those public commands together with Install-SqlDscServer -Upgrade is used together in a class-based resource (suggest looking at other class-based resource how they are built, for example SqlAudit).

All of this should be tested using

unit tests
and if possible an integration test if it possible to install a lower version of SQL Server and then update it using a CU (probably not).

What is the development process for this? Just edit the files in PSMODULEPATH?

Please look at https://dsccommunity.org/guidelines/getting-started/ and then https://dsccommunity.org/guidelines/contributing/#create-or-update-a-pull-request-pr

To test it you would probably move the built module from the dev machine to a lab machine in machine-wide path of PSMoudulePath where you test it easiest using Invoke-DscResource

How would you implement This? I took a look at dbatools's implementation, they seem to maintain a json that contains all SQL server versions and all their CUs. That's quite a lot of maintenance to do.

We should not have any versioninformation that needs to be maintained in this module. That is input parameters to the DSC resource and subsequently to the public commands. But I don't see the need to use versions as input parameters. Input parameters should probably specify the path to where the updated package is. Version is determined by the package and installed SQL Server instance. Unless you find another clever way. 🙂

Uh oh!

Minor version upgrade of already installed SQL Server instance #2053

Description

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions