SubPointSolutions / MetaPack

A NuGet platform for packaging, delivering and deploying SharePoint customization with PnP/SPMeta2 support.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

CLI - implement "metapackfile" and "metapackfile.lock" concepts

SubPointSupport opened this issue · comments

MetaPack CLI should have a concept of "metapackfile" and "metapackfile.lock" similar, for instance, to Ruby's "Gemfile" and "Gemfile.lock"

Both "metapackfile" and "metapackfile.lock" aim to support the following scenarios:

Package deployment orchestration

metapackfile describes mappings between SharePoint site urls (or connections) and packages to be deployed. JSON or Yaml can be seen as following:

galleries:
    - url: http://metapackgallery.com/api/v2
    - url: https://packages.nuget.org/api/v2
    - url: http://www.myget.org/F/subpointsolutions-staging/api/v2

deployments:
    - TeamSite:
        name: team-site        
        url: https://contoso.sharepoint.com/sites/intranet
        spversion: sp2013 | sp2016 | o365
        spapi: csom | ssom
        packages:
            - id: contoso.metadata
              version: 1.0.0
            - id: contoso.teamsite
              version: 1.2.0-beta1
    - LeaveRequestSite:
        name: leave-request-site
        url: https://contoso.sharepoint.com/sites/intranet/leave-request
        packages:
            - id: contoso.leaverequest
            - id: contoso.teamsite
              version: 1.2.0-beta1          

Such yaml aims to define:

  • NuGet galleries to be used
  • Mappings between target SharePoint sites (urls) and packages to be deployed

JSON representation can be seen as following:

{
  "galleries": [
    {
      "url": "http://metapackgallery.com/api/v2"
    },
    {
      "url": "https://packages.nuget.org/api/v2"
    },
    {
      "url": "http://www.myget.org/F/subpointsolutions-staging/api/v2"
    }
  ],
  "deployments": [
    {
      "TeamSite": {
        "url": "https://contoso.sharepoint.com/sites/intranet",
        "packages": [
          {
            "version": "1.0.0",
            "id": "contoso.metadata"
          },
          {
            "version": "1.2.0-beta1",
            "id": "contoso.teamsite"
          }
        ],
        "name": "team-site"
      }
    },
    {
      "LeaveRequestSite": {
        "url": "https://contoso.sharepoint.com/sites/intranet/leave-request",
        "packages": [
          {
            "id": "contoso.leaverequest"
          },
          {
            "version": "1.2.0-beta1",
            "id": "contoso.teamsite"
          }
        ],
        "name": "leave-request-site"
      }
    }
  ]
}

Credential managements is to be define later but here are a few options:

  • credentials section within yaml config
  • other ways to reference credentials within deployments section in a secure way

Such configuration would enable orchestration of a complex provision over multiple packages, SharePoint sites and tenants. Configuration is a pure draft, to be refined and enhanced as we go.

The other bit of the configuration is "metapackfile.lock" file.
The aim is to lock down versions of the packages per SharePoint sites. That should be done by similar yaml/json config in the following way:

locks:
    global:
        packages:
              - id: contoso.metadata
                version: 1.0.0
              - id: contoso.metadata.fields
                version: 1.2.0     
    local:
        - url: https://contoso.sharepoint.com/sites/intranet
          packages:
              - id: contoso.metadata
                version: 1.0.0
              - id: contoso.metadata.fields
                version: 1.2.0     
        - url: https://contoso.sharepoint.com
          packages:
              - id: contoso.intranet
                version: 1.2.0
              - id: contoso.metadata.fields
                version: 1.2.0                    

Global locks - all packages across the board.
Local locks - packages per particular site url.

The aim is to lock down versions which would (can be) deployed to target urls by default. MetaPack would check information in "metapackfile.lock" finding particular versions of the packages before deployment.