ServiceNow CI/CD pipeline for Citizen Developers

 

Automate your ServiceNow CI/CD pipeline for Citizen Developers

In this article I’m going to walk you through how to set up the CICD pipeline for citizen developers or no/low code developers. Note: the article doesn’t take into account the app engine management center (AEMC) app, which is part of the PRO license.

Set up the Application Intake (via the guided setup)

Application Intake Guided Setup

Login to your Production instance and follow the steps bellow.

Turn on and configure the intake request process

This step requires you to activate the catalog item on your production instance, then add users to the App Engine Admins group. As you add users, remember that only members of this group can approve catalog requests for app intake.

Activate the catalog item where developers will submit their application ideas

Activate the Application Intake form so that developers can start submitting their application ideas with the app intake request form. If their application idea is approved, they can start developing applications using app development tools on the development instance.



After activating the Apply for Citizen Development item you should have access to it in the service portal:


The workflow behind the item is as follows: the requestor (logged in user) raises a request to apply for citizen development from the service portal in PROD. After approval (of the REQ and not the RITM) the user gets added to the selected group in DEV. This will enable the user to work in DEV and push his/her apps through the AEMC pipeline. The approvers reside in the App Engine Admin group.

Set up App Engine Admins group

The App Engine Admins group contains users who can approve and reject app intake requests and other App Engine-related requests. Add an email address for the group and add members to the group so that they can receive notifications related to app development.

Note: don’t forget to add the proper users to the App Engine Admins group.

Configure development environments for users

Set up and configure the environment records associated with the development instances that users will be provisioned to. You will need an environment record for each of the development instances.

Create development environment records

On your production instance, create an environment record of type "Development" for each development instance that you want to provision users to. This will allow your production instance to connect to your development instances.

Procedure 
  1. Navigate to App Engine > Pipelines and Deployments > Environments
  2. On the environment page, create these environments: PROD, DEV and TEST on Application Intake scope
For example, PROD environment:


Remember to Validate the environments.

Note:

If you get the 401 error message: 


It means that your functional account is misconfigured.

If you get the 403 error message: 


It means that you have to add a role (i.e., admin role) to the functional account to enable login.

This is the message you should when an environment gets successfully validated:


Other notes:
  • You can find the instance ID in the /stats.do
  • For configuring environment credentials see topic below (Configure environment credentials)
  • Regarding the PROD environment make sure you activate the 'Is Controller?' box
  • Repeat the last step (via the guided setup) on every other sub-prod environment in the pipeline. So, if you have configured the PROD then do the same for DEV and TEST
  • Once you have configured the development environments in PROD, it's easier to import them via XML in other other sub-prod environment
  • In sub-prod environments it’s not necessary to activate the Apply for Citizen Development item

Set up Pipelines and Deployments (via the guided setup)

Pipelines and Deployments Guided Setup

Configuring your PRODUCTION instance

On your production instance, configure your pipelines and associated environments to streamline your app deployment process.

Configure environment credentials

A credential record enables pipeline flows to access each environment in the pipeline. To set up a credential record, use an account that has admin permissions on every environment in the pipeline.

It's recommended that you use a functional account and not an account associated with an individual person. Permissions may change on individual accounts, which could prevent the pipeline from running.

Procedure
  1. Type connections & credentials in the navigator bar and click on the link to Connection & Credential Aliases page
  2. Create new Connection & Credential Aliases (sys_alias) in global scope
    1. Type: Credential


  3. Create new Credentials (recommended: Basic Auth Credentials)
    1. Remember: create a functional account (ex: sa-sn-aemc-pipe in the user table) for creating credentials


  4. Create the account (above) on every environment in the pipeline
    1. Repeat this step (use this account that has admin permissions) in every environment in the pipeline. For instance, if you have three environments (DEV - TEST - PROD) you need to set up this account in all the three envs
    2. Note: instead of creating the functional account, the credentials and the connection & credential aliases from scratch on every sub-prod instance, you can easily import them from PROD
Configure environments

Refer above to: Create development environment records

TLDR

Set up and configure the environments that will be included within your pipelines. These will be referenced when building your pipelines. Your production instance is where your pipeline configurations reside and will be your controller instance. 
  • The 'Is Controller?' box should be checked on your production environment record. 
  • The 'Is Controller?' box should be unchecked on your non-production environment records.
Note: just as with importing credentials you can also import environments in other sub-prod instances from PROD.

Configure pipeline

Set up and configure your pipelines by specifying the environments (yes, in all ENVs) to be included, as well as their positions in the pipeline.

Procedure
  1. Before creating the AEMC CICD pipeline ensure the Application Deployment Pipeline Type is already configured:
    1. /now/nav/ui/classic/params/target/sn_pipeline_pipeline_type.do%3Fsys_id%3D268f9c0fb73430100290b9708e11a9de%26sysparm_view%3D
  2. Change scope to: Deployment Pipeline
  3. Navigate to sn_pipeline_pipeline table and create the pipeline:
    1. Provide a name
    2. Pipeline Type: Application Deployment
    3. Source Environment: DEV
    4. Select Active box
  4. Create the Pipeline Environments Order of the newly created pipeline
Notes:
  • There is no need to add DEV in the related list (Pipeline Environments Order) since it’s the source env.
  • Repeat the last step (via the guided setup) on every other sub-prod environment in the pipeline. So, if you have configured the PROD then do the same for DEV and TEST
  • Once you have configured the development environments in PROD, it's easier to import them via XML in other other sub-prod environment
Add Automated Test Framework (ATF) and Instance Scan suites

Any tests that are in the "Scan Suites" table will run in each testing environment in the pipeline. By default, one ATF suite and one Instance Scan suite are included, but you will need to add them to your pipeline by populating the default suites in the "Scan Suites" table. You can also add additional suites from your testing environments. Remember: this is still in the production instance.

You can only create or modify these suites while configuring your testing environments.

Procedure
  1. Navigate to App Engine > Pipelines and Deployments > Scan Suites
  2. Click on Populate default suites
The ATF and Instance Scan suit should be populated.

Enable Change Management integration

Once enabled, deployments through the pipeline to the production environment will be automatically scheduled based on the Change request state and planned change window.

Procedure
  1. Navigate to system property (sys_properties.list) > sn_deploy_pipeline.change_management.enabled
  2. Change value to: true
Configurable properties to integrate Change Management

Configure Change Model

Configure the sys_id of the Change Model that you would like to use for each Change request created during deployment.

If not configured, the 'Normal' Change Model will be used by default.

Procedure
  1. Navigate to System Property > sn_deploy_pipeline.change_management.default.model
  2. Paste the sys_id (of the change model)
Configure Change Template

Configure the sys_id of the Change Template that you would like each Change request to be created from.

Procedure
  1. Navigate to System Property > sn_deploy_pipeline.change_management.default.template
  2. Paste the sys_id (of the change template)
Configure CI Creation Subflow

By default, Create CMDB CI if not present subflow will run automatically during deployment. If you would like to change how Configuration Items(CIs) are created during deployment, copy the Template: Create CMDB CI if not present subflow template, modify it, and come back here and configure the sys_id of your new flow.

Procedure
  1. Navigate to System Property > sn_deploy_pipeline.change_management.config_ci_creation_subflow
  2. Paste the sys_id (of the change template)

Configuring your TESTING instance

On your Testing instance, you'll need to set up and configure a controller instance. The controller instance is an environment record that will point to you production instance. This instance will also run the Automated Test Framework (ATF) and Instance Scan suites during the deployment process once you enable and configure them.

Configure environment credentials

Note: refer to Configure environment credentials in production (above). This step should already be done.

Configure the controller instance

Set up and configure the environment record that will point to the production instance, where your pipeline configurations reside. All deployment requests will be routed through this instance to trigger the deployment process. Until this is configured, your developers will not be able to submit deployment requests. Repeat this task on each non-production instance that will be part of a pipeline.

Procedure
  1. Navigate to Environments
  2. Set up PROD env as the controller env
Enable Automate Test Framework (ATF) properties 

Enable the system properties that will allow the ATF suite to run during the deployment process. If you do not enable these properties, you will receive a warning during the deployment process but will be able to continue with your deployment. If you want to clone your "production instance" to any "non-production instances", you should enable this property on your production instance, also.

Procedure
  1. Navigate to Automated Test Framework (ATF) > Administration > Properties
  2. Enable these two properties and click save
Configure Automated Test Framework (ATF) suite

The default Automate Test Framework (ATF) suite is included, but you can add test cases to it. This test suite will automatically run on each app that is installed on this "test instance" during the deployment process, if added to the "Scan Suites" table on the production instance. To run additional ATF suites on each app, you will need to add them while you are configuring your production instance.

Procedure
  1. Navigate to Automate Test Framework (ATF) > Suites
  2. Open Application Deployment Test Suite
  3. Check Active box
Configure Instance Scan suite

The default Instance Scan suite is included, but you can add checks to it. This suite will automatically run on each app that is installed on this "test instance" during the deployment process, if added to the "Scan Suites" table on the production instance. To run additional Instance Scan suites on each app, you will need to add them while you are configuring your production instance.

Procedure
  1. Navigate to Instance Scan  > Suites
  2. Open Scoped App Definitions
  3. Check Active box

Configuring your other NON-PRODUCTION instances

On your non-production instances (i.e., DEV), set up and configure the environment record that will point to your production instance - controller instance.

Configure environment credentials

Note: refer to Configure environment credentials in production (above). This step should already be done.

Configure the controller instance

Note: refer to Configure the controller instance in production (above). This step should already be done.



Reference:

Comments

Popular Posts