Skip to main content
Developer Network

Deploy Packages

Deployment Package - Integration Lifecycle Management

The deployment package is a collection of all the individual integration modules that you would have created and configured for your product integration. The individual modules are Vendor Defined Fields, Vendor Defined Alerts, Deployment of Third-party product solutions, Vendor Defined tasks, connections, and callbacks, etc. Deployment packages are used to deploy your integration to the sandbox and subsequently to production.

For e.g. If you are a vendor and for your product integration you just need Vendor defined fields, then you must first create Vendor Defined fields. Once you have created the Vendor Defined Fields, you need to create a deployment package. This package then becomes your product integration which can be deployed to the sandbox and production environments via a defined process.

Deployment Package Page in the Vendor Development Portal

You can do the following in the Deployment package section in the vendor development portal:

  • Create new package
  • Delete package
  • Deploy the package to the sandbox
  • Request package to be reviewed for Production release
  • View which package is live on Sandbox
  • View which package is live on production
  • View activity log for each package (when was package create, who created, when was it deployed to the sandbox, etc.)
Process for Development and Deployment of a Vendor Product Integration

The process is similar to the concept of a build deployment process that we follow in a regular software development lifecycle. Complete all the changes/configuration/setup that you would like for each individual integration module in the vendor development portal and create a package that would contain all those changes. You can then use the package to promote it to the sandbox - test and validate and further to production. See the below chart for the Integration deployment lifecycle:

3rd-process.png

Step 1: Configure and Setup

Configure all the Integration modules that you want for your product integration. This may include defining the vendor-defined fields by supplying the JSON schema, define the alerts by supplying the payload for the alerts per condition id, defining the schema for accepting connection credentials from partners, and defining the callbacks, specifying the product deployment and installation instructions, and providing task definitions. For details on how to configure and set up each individual section, refer to its documentation provided in respective sections. Individual modules can be configured and set up from the Vendor Development portal. See the following screenshots for logging in to the Sandbox, switching to the development portal, and accessing each individual integration module for configuration

1.png1b.png1c.png

Step 2: Create Package

Once you have configured and set up all individual modules, you need to go to the Deployment Package page in the development portal and create the deployment package. See the following screenshot which shows the Deployment package page and highlighted red-colored box for creating a new package.

2.png

Step 3: Deploy the Package to the sandbox

Once you have created a new package, you need to deploy that package to the Sandbox. This can be done by selecting the relevant package in the grid and then clicking on the highlighted red-colored button "Deploy to Sandbox".

3.png

Step 4: Test and validate the Package in the sandbox

After deploying the package to the sandbox, all the configurations, and settings that you would have defined in the individual integration modules would be deployed to the sandbox where you can test and validate your integration. In the Sandbox, you will be able to view and set up things as the partner would. Switch to the sandbox to view all the new changes.

You can repeat steps 1 to 4 until you have successful test and validation for all the integration modules in the Sandbox.

Step 5: Request for Production deployment

If all the tests and validations are successful in the sandbox and you no longer need to make any further changes to the integration modules, you can request the package to be deployed to the production and make it available for partners in the ITSupport portal. Once you initiate the request, we would further validate and test the package based on business and security parameters via an offline process. Review can either be a success or a failure if successful we would deploy the package to the lower environments of the ITSupport portal, test it and then promote it to production. See the screenshot below, you can request a review for a package by selecting a package and clicking the red-colored button.5.png

Package Statuses
  1. Sandbox-ready - When you create a new package, it would be in the "Sandbox-ready" state
  2. All the packages in the "Sandbox-ready" state can be deployed to the sandbox, once deployed status would change to "Deployed on Sandbox"
  3. Package in the status "Deployed on Sandbox" can be requested for review for production deployment. When requested for review, the status would change to "Review-requested"
  4. If review is successful, the status of the package would change to "Deployed on Production"
  5. If the same package is deployed on both, sandbox and production, the status would change to "Deployed on Sandbox and Production"

Deployment Packages have the following rules:

  • At any point in time, there can only be one package deployed on the sandbox
  • At any point in time, there can only be one package deployed on the production
  • At any point in time, there can only be one package for which you can request production deployment
  • A package that is either deployed on sandbox or deployed on production or is under review for a production deployment cannot be deleted
  • The package follows simple versioning - every new package you create will get a new version number, each time incremented by 1 (The first package will have Version no. 1, then 2, 3, and so on.)
  • A package when created goes through certain automated tests where we perform security/sanity checks. In the event, if these tests fail, the respective package will be automatically marked as Blacklisted and you will not be able to deploy such packages on production