Pipelines and Deployments workflow version 24.1.2

  • Release version: Yokohama
  • Updated January 30, 2025
  • 4 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Pipelines and Deployments workflow version 24.1.2

    The Pipelines and Deployments workflow version 24.1.2, released with Yokohama in November 2023, streamlines how app deployment requests are processed through pipelines in the App Engine Management Center (AEMC). This workflow automates validation, deployment, approval, testing, and change management steps to ensure controlled and reliable application deployments across environments.

    Show full answer Show less

    Workflow Process Details

    • Request Submission: A requester submits a deployment via App Engine Studio, triggering automated validation and creation of a deployment request on the controller instance.
    • Notification: The requester receives an email confirmation that the request has been created.
    • App Publication: The application is published to the Application Repository. If errors occur with severity "Error," the system creates an approval step before proceeding.
    • Environment Progression: The workflow checks for the next environment in the pipeline:
      • If none exists, the requester is notified of completion and the workflow ends.
      • If there is a next environment, the deployment request updates the target environment and awaits approval.
    • Approval Handling: If approval is denied, the requester is notified and the workflow ends. If approved, different actions occur based on the target environment:
      • Testing: The app is deployed to the test environment if not already present. Automated tests, including Scoped App Definitions Instance Scan and Application Deployment Test Suite (ATF), run with results recorded and displayed.
      • Production: The deployment integrates with Change Management:
        • Change requests are created and linked to the app configured as a Configuration Item (CI).
        • The workflow monitors the change request state, awaiting "Implement" status and the planned start date.
        • Upon conditions met, deployment is scheduled, and the deployment request and change tasks are closed.
        • If the change request is rejected or canceled, the requester is notified and the process ends.
      • Other Environments: The app is deployed directly if not already present, then the workflow cycles back for new submissions.

    Key Benefits for ServiceNow Customers

    • Automated and Controlled Deployment: Streamlines deployments with automated validation, approval gating, and environment-aware processing.
    • Integrated Testing and Quality Assurance: Incorporates automated scans and testing suites to ensure deployment quality before production rollout.
    • Change Management Integration: Aligns production deployments with change requests and approvals, improving governance and auditability.
    • Clear Notifications: Keeps requesters informed at every critical step via automated email communications.
    • Flexible Pipeline Progression: Supports multi-environment pipelines with conditional logic based on errors and approvals, adaptable to organizational deployment strategies.

    As you manage requests for app deployment in App Engine Management Center (AEMC), use this workflow to understand how app deployments move through your pipelines in version 24.1.2, released in November 2023.

    Figure 1. Pipelines and Deployments workflow
    Infographic depicting a standard Pipelines and Deployments workflow. For a text description, refer to the workflow steps that follow.
    In this workflow:
    1. The requester selects Submit in App Engine Studio, which triggers the main flow.
    2. The system performs the following tasks behind the scenes:
      1. Validates the payload.
      2. Fetches the App Manifest from the sys_app record on the source instance.
      3. Creates a deployment request on the controller instance.
      4. Sends an email from the controller instance to notify the requester that the request was created.
      5. Publishes the application to the Application Repository.
    3. The system performs different actions depending on if there are errors or not during publication.
      1. If there are errors in the app publication, and the error severity is Error, then the system creates and waits for approval for the updated record.
      2. If there are no errors, or if there are errors, but the error severity isn’t Error, then the system looks up the next environment on the Pipeline record.
        1. If the next environment doesn’t exist, the system sends an email from the Controller instance to notify the requester that the request was closed and the app has been published to the target instance. This action ends the workflow.
        2. If the next environment does exist, the system updates the Target environment field on the deployment request to the next environment. Then, the system creates and waits for approval for the updated record.
    4. The system performs different actions depending on if the new record was approved.
      1. If the record isn’t approved, the system sends an email from the Controller instance to notify the requester that the request wasn’t approved and the request has been closed. This action ends the workflow.
      2. If the record is approved, and if the Target environment is Testing, then the system performs the following actions:
        1. Deploys app to test environment, if the app is not available there.
        2. Runs the Scoped App Definitions Instance Scan and any other suites on the Scan Suites [[scan_suites]] table on the Testing instance.
          Note:
          The Scan Suites table should be populated on the Controller instance.
        3. Runs the Application Deployment Test Suite Automated Test Framework (ATF) suite and any suites on the Scan Suites [scan_suites] table on the Testing instance.
        4. Writes Instance Scan and ATF test results to the Deployment Environment Result table and to the Activity Stream on the deployment request.
        5. Returns the workflow to step 3, where it checks for errors.
      3. If the record is approved, and the Target environment is Production, the app begins the scheduled deployment process with Change Management integration.
        1. The App Engine Admin selects Approve & Create Change request. A change request is created based on the template chosen during Guided Setup.
        2. The system performs different actions depending on if the app is registered as a configuration item (CI).
          1. If the app is not registered as a CI, the system registers the app as a CI and then adds the affected CI to the change request.
          2. If the app is registered as a CI, the system adds the affected CI to the change request.
        3. The system performs different actions depending on if the change request is in the Implement state.
          1. If the change request state is not Implement, and the state is not Assess or Authorize, the system sends an email from the Controller instance to notify the requester that their request was not approved and has been closed. This ends the workflow.
          2. If the change request state is not Implement, and the state is Assess or Authorize, the system waits for the state to be Implement.
          3. If the change request is in the Implement state, the system creates a change task to schedule the app deployment.
        4. If the change request state is Implement and the Planned Start Date is not Now or in the past, the system waits for those two conditions to be true
        5. If the change request state is Implement and the Planned Start Date is Now or in the past, but the request is Rejected or Cancelled, the system sends an email from the Controller instance to notify the requester that their request was not approved and has been closed. This ends the workflow.
        6. If the change request state is Implement and the Planned Start Date is Now or in the past, the system schedules the app deployment to Production based on the Planned Start Date in the change request. The system closes the change task, and then closes the deployment request. This ends the workflow.
      4. If the record is approved, and the Target environment isn’t Testing or Production, then the system deploys the app to the target environment, if it isn't available there.

        The workflow starts over when a requester selects Submit again in App Engine Studio.