Shifting from Dev to Production: A Comprehensive Guide

About 3 min

As you prepare to move from the development phase to the production phase, we have curated this comprehensive guide to assist you every step of the way. The purpose of this document is to facilitate your journey from development to production, pointing out essential considerations to ensure a smooth and seamless transition.

Identity Provider (IdP) Configuration

During your test phase in the development environment, you would have already configured at least one Identity Provider (IdP) in the Datawiza Cloud Management Console (DCMC) and within the IdP console, like Azure Portal or Okta Dashboard.

For optimal security and configuration management, we recommend creating new IdP entries in both the DCMC and IdP console for production use. This enables you to maintain separate configurations for development and production. Crucial aspects, like user restrictions or Multi-Factor Authentication (MFA) settings, can be tested in the development environment before deploying to production.

Datawiza Cloud Management Console Part

Just as with the IdP setup, you likely have configured at least one deployment in the DCMC during your development testing phase. Given that there are deployment-based configurations within the DCMC, it's practical and advantageous to maintain separate deployments for your development and production environments. Consequently, we highly recommend creating a completely new deployment configuration within DCMC to handle your transition to the production environment.

This segregates the settings, limits the risk of errors, and effectively allows you to manage resources and configurations that are unique to each environment. Hence, this approach is beneficial in ensuring the stability and performance of your production environment without affecting ongoing or future developments.

Using the Duplicate Function for Migration

To simplify the migration process, we provide a duplicate function. This function allows you to completely duplicate a deployment configuration, including applications and IdPs. Instead of manually adding applications/IdPs one by one, you can migrate everything at once.

Important: After duplication, update the application URLs and IdPs for the production environment.

Migration Example

Here is an example of how to use the duplicate function for migration. Suppose you have a Dev deployment with two applications, Dev-1 and Dev-2, and you want to create a Prod deployment with Prod-1 and Prod-2. Dev to Prod

Step 1: Duplicate the Development Deployment

Navigate to Deployments and click Duplicate on the Dev deployment:
Provide a name for the new deployment and confirm:
The Prod deployment will be created:

Step 2: Update Application Settings

Open the Prod deployment to review the duplicated applications. Update the application names, URLs, and upstream configurations to match the production environment:

Step 3: Configure Identity Providers (IdPs)

By default, the IdPs of the Dev application will be copied as well. If you want to reuse the IdPs from your development environment. Update the IdP callback URLs to include the production URL. We use Entra ID here as the example: select the development app registration, navigate to Authentication, and add Redirect URIs for the production environment:

Step 4: One-Click Entra ID Setup (Optional)

For convenience, we provide a one-click function to create a new app registration in Entra ID for the production environment: By following these steps, you can efficiently transition from development to production with minimal effort, ensuring a seamless and error-free deployment.

Transitioning to Production

When your development tests are accomplished, and you're ready to move to production, here are our recommended steps:

Preparing for Transition (can be done at any time before going live): Use the DCMC to configure a new deployment, application, and IdP. For the upstream servers, initially opt for Dummy Application. This built-in configuration serves as a header-based application to read and display request headers.
Setting up Datawiza Access Proxy (can be done at any time before going live): Set up and deploy the Datawiza Access Proxy on a new server and update the local DNS to point to your intended production domain. Test out the login flow and attribute pass (if necessary) right on this server.
Initiating Production Phase (to be done when officially transitioning to production): When you are ready to go live with your production service, update the DNS and upstream servers to your production environment settings.

This approach ensures that you have a well-prepared and thoroughly tested system before going live, thus minimizing any potential risks or setbacks during the transition to the production phase.

Rollback Plan

Should you encounter any issues in the production phase and need to rollback, the task is quite straightforward. Simply roll back both the DNS and your service to their previous states.

Important Notice

For a header-based authentication system, it's important that the application is only accessible via the proxy, as the application trusts the request header sent from it. To understand how to add restrictions to your service, please refer to this guide.