Provisioning
Overview
The glueckkanja-gab Software Provisioning Service delivers a standardized package lifecycle process for RealmJoin software packages. With the Software Provisioning Service, all software packages are managed by a dedicated team of experienced engineers providing all services from initial request to decommissioning of software packages.
Cost base
The costs are based on the total number of managed software packages and are determined in advance. A readjustment can be made at any time in consultation with the parties.
Standard services and tasks
The following section lists the standard tasks and services included in the service.
- Providing an extended package request flow
- Accept new package requests
- Logical quality check of package requests (check for similar software, newer versions, known issues)
- Technical quality check of package binaries (completeness, compatibility, dependencies)
- Check and decision for optimal package format
- Check and coordinate optional parameters and their defaults
- Coordinate creation of new packages with the packaging team
- Coordinate creation of updated packages with the packaging team
- Management of prerelease packages and request for approval
- Releasing approved packages
- Autonomous release of managed application updates
- Monitoring the lifecycle of dependencies
- Provide the metadata management of packages (UPN, cost center, other data)
- Optional: Management of the scoped AAD groups (APP-* groups within customer tenant with correct name-schema)
- Decommissioning of packages
- Management and archiving of binaries and packages
Process Flow
To realize an efficient and auditable process the communication between the Application Owner and the Customer Delivery Team shall not use direct email. Instead, the initial request needs to be made on a request portal described later in this document. By using the portal the identity of the application owner is proofed and additional information (cost center, authorized representative, sponsor, etc.) can be collected. When the request is created the ongoing communication is ticket driven within the Customer Delivery Team but the Application Owner will be able to stay in the loop by using standard email but connected to the provisioning ticket. In addition to the above flow, the Customer Delivery Team can provide the service to create Azure AD groups for preview and production use of the requested package and bind these groups to the parameterized package deployment assignment in RealmJoin. Similar tasks are related to the complete lifecycle of an application including the maintenance of updates, dependencies, decommissioning, and archiving.
Provisioning Portal
Every creation or updating request for deployment packages should be made in the provisioning portal provided by glueckkanja-gab. The implementation will be extended to provide Packaging Request Form (PRF) blocks (secure uploading capabilities are already available but some data should be extracted and used for the flow) and additional metadata with some to be discussed with the customer to provide optimized integration in billing and controlling flows. Already known metadata is the cost center code.
Quality Check Procedures
The quality assurance (QA) process includes a logical and technical part. First of all, a logical QA with an investigation about already existing packages of the same or similar content is started. This includes a check for newer versions which in general should always outvote a request for an older version. In addition, a basic background check about the vendor and the trustworthiness of the software is done. If anything fails in the logical QA a decision tree settled with the customer is started. The regular outcome is the use of the existing package or the cancellation of the request. If the application owner insists against the logical QA an escalation to a customer named person may start and the formal decision may be made to continue against the logical QA status. When the logical QA is done a technical QA starts and the compatibility with the modern workplace is checked. This includes operating system compatibility, dependencies of legacy technologies (fileserver, domains, etc.), outdated technologies (old browsers, etc.), software dependencies (.net, Java, other). In addition, the provided setup package is checked for completeness and functionality. Again, if anything fails in the technical QA a decision tree settled with the customer is started.
Management of prerelease packages
In general, a Provisioning-as-a-Service-Contract includes the handling of Azure AD application groups. If this is the case, the Customer Delivery Team maintains the application groups during the lifecycle of a package. When a pre-release package is available a respective group is created and the pre-release package is assigned. The assignment of users should not be part of the deliverables. This decision should be done by people responsible for the usage, licensing, and target group of a package.
Release to production
If a package is approved for release by the Customer Delivery Team a respective group is created and the released package is assigned. Depending on several parameters the deployment details are varying: mandatory vs optional, staggered deployment, background deployment, etc. The actual rollout to users or computers is controlled by the group membership of users in the group.
Decommissioning and Archiving of Packages
If a package is end-of-life by superseding or not used anymore the decommissioning is done by the Customer Delivery Team if requested by the application owner or triggered by market knowledge. Uninstall packages are created if necessary and the Azure AD groups and assignments are out phased. The package is still available archived within the provisioning backend.
On-Demand services and tasks
The tasks and services described in the following section are not included as part of the Service but may be requested and delivered via On-Demand Services.
Ramp-Up
The initial commissioning and setup of our service is defined as ramp-up and is not part of our service. The ramp-up can be carried out via on-demand services or consulting services.
Customer requests and incidents
Requests that do not fall into the items listed under Standard services and tasks and are from direct customer requests will be treated as a normal change and serviced through On-Demand services.
Prerequisites
Services
An IT-Service agreement with glueckkanja-gab is required. The glueckkanja-gab Service Level Agreement and Request definitions also apply to this Service Description.
The Client Module is required as the basis for the Software Module.
Requirements
The packaging lab can only perform quality tests, but not functional and integration tests. Technical contact for the respective software and processes for testing and releasing packaged software must be provided by the customer.
License
The Customer is responsible for the correct licensing of all Microsoft services and other Software used and affected.
Optional
- Optionally, the customer can add one of the on-call duty packages (defined in more detail in the Service Level Agreement).
Exclusion
The Provisioning Service cannot handle software requests without comprehensive documentation. The preparation of such documentation is not part of the service.
License management is not part of the service and cannot be supported. The customer has full responsibility for the correct execution and procurement of licenses of the software to be packaged.