Best practices for deploying Ignition 8 (2023)

Introduction

The purpose of this guide is to help you better understand how to deploy Ignition applications and provide some best practices for setting up your development and testing workflow. A solid implementation workflow enables better change management, minimizes errors and leads to a more productive team.

This guide is intended for Ignition users who want to set up a scalable, flexible, enterprise-class system. Some users assume and then move on to a different architecture or model, and some users may never decide to implement all of the recommendations. These guidelines are not intended to be an all-or-nothing proposition and many installations could benefit from applying even some of the recommendations contained herein.

For any enterprise-class system, Inductive Automation strongly recommends using all of the techniques discussed in this document.

Work flow

Deployments should be treated as part of the development process, not as an afterthought. Your workflow typically includes at least three environments: development, testing, and production. In this case, the workflow might look like this:

1. Developers work on bugs and features in a development environment.
2. Once features are deployed, they are integrated into the testing branch and placed in the testing environment for QA and testing.
3. After testing is complete, the development branch is merged with production and then deployed to the production environment.

Before we dive deeper into each environment, it's important to take a closer look at how Ignition is configured to better understand the deployment.

Ignition configuration

Ignition is server-based software and is installed on a central server. This means that the entire Ignition configuration is stored on the server. It is a central location for installation, licensing, configuration, security and management. Client applications are downloaded from the Ignition server (Vision) or are native HTML (Perspective) and are therefore automatically updated as new changes are made. This way we don't have to worry about installing, licensing or deploying changes to individual customers, especially when we have hundreds of customers. Our deployment model allows us to focus solely on the server.

When developing in Ignition, there are four main configuration areas:

• Gateway configuration
• keywords
• Such an
• project

Each of these areas is stored on the server in a different way. The gateway backup contains the configuration for all, but some can be edited individually. It is important to understand the differences and how we communicate them when making changes.

Gateway configuration

The gateway configuration area contains all the different settings, profiles, and connections that you edit in the configuration section of the gateway website. Most settings that affect the entire gateway are made here. We can add databases and device connections, users and roles, customize alarm settings, set up security, schedule a gateway backup to be created automatically at a specified time, and much more. The list of configuration options in the left menu changes depending on which modules are installed on your gateway.

All of these settings are stored in Ignition's internal SQLite database. They are only available through the gateway user interface. Outside of a full gateway backup, you canYou can notExport or import these settings from gateway to gateway. Ignition's EAM module also currently does not support moving these settings from gateway to gateway. This makes it difficult to work on developing our implementation strategy as all changes need to be implementedmanual. It's also hard to track changes because everything resides in a SQLite database.

Gateway backups are usually not used when migrating changes because it is all or nothing. Different environments often have separate gateway configuration settings for items such as devices, databases, and authentication.

We recommend creating a process that all developers follow to track changes to these settings outside of Ignition and to document differences in these settings within each environment (dev, test, and production).

keywords

Tags are an important part of most projects. Tags are data points and can have static or dynamic values ​​that come from an OPC address, expression, or SQL query. Values ​​can be used on screens, in transaction groups, etc.

Tags provide a consistent data model across Ignition and provide the easiest way to start creating real-time status and control systems. However, despite their fast initial learning curve, tags offer great opportunities in system design and configuration. The ability to merge tags from different installations means it's easier than ever to build widely distributed SCADA systems with high performance and relatively simple configuration.

Tags are stored within the tag provider. are brandsit isPart of the ignition project. Instead, projects are all about tags. A tag provider is a tag collection (tag database) and can be local or remote. One or more tag providers can be associated with the ignition server. Tag providers can provide logical grouping of tags (separate tag repositories). Ignition comes with a local tag provider called "default" by default. Local tag providers are stored in Ignition's internal SQLite database. Tags are configured in the Ignition Designer in the Tag Browser panel.

Ignition can export and import markup configurations in JSON (JavaScript Object Notation) file format. You can also import XML (Extensible Markup Language) or CSV (Comma Separated Value) file formats, but Ignition converts them to JSON format.

Tags can also be moved from gateway to gateway through Ignition's EAM module. Tags are much easier to work with when making changes. However, tags are still stored in Ignition's internal SQLite database and steps must be taken to track tag changes.

We recommend continuously exporting tags to a JSON file and committing the file to a source control repository to track changes. The tag export process can be done automatically using a Python script in Ignition (more details to follow). You can use Ignition's EAM module to push changes from development to testing to production, or export/import manually via Ignition Designer.

Such an

Images such as PNG, JPG, GIF and SVG can be loaded into the Image Manager and used in Vision or Perspective. The Image Manager tool, available under Tools > Image Management in Ignition Designer, provides an interface for uploading, downloading, or selecting images.

These images are stored in Ignition's internal SQLite databaseit isPart of the ignition project. Instead, projects are all about images.

Such anYou can notmoved from gateway to gateway using Ignition's EAM module. The process is manual and requires the use of the image management tools in Ignition Designer. Measures should also be taken to monitor image changes.

We recommend continuously exporting images to a folder and committing the folder to a source control repository to track changes. This procedure cannot be performed automatically and requires manual intervention. You must export/import images through Ignition Designer when deploying changes from development to testing to production.

project

Projects are the main unit of configuration in Ignition. Projects contain all the designed elements that do the actual work. Your projects can contain both interactive elements (such as controls, charts, reports, input forms, etc.) and permanent elements (such as historical logs, automated reports, etc.).

In Ignition, a project is a unit of configuration that contains:

• Vision windows and templates and perspective views: the screens that users interact with
• Transaction groups: two-way connection between databases and PLC
• Reports: PDF reports to view and record data
• Scripts: Timer and event-based scripts used throughout the system
• Alarm Notification Pipelines: Pipelines that notify users of alarm conditions
• General settings and properties: Settings that control access, resource links, appearance, time, and more.
• And much more

Configure and build projects with Ignition Designer. Projects are then viewed at runtime (Vision Clients or Perspective Sessions). You can create as many projects as you want, and users can easily switch between projects instantly or open multiple projects at once.

Projects are stored in the file system as a series of folders and files. Some files are binary, others are saved as plain text files. Projects are stored in the data directory on the Ignition server.

Linux

/var/lib/ignition/data/projects

ramen

C:\Programs\Inductive Automation\Ignition\data\projects

Because projects are saved to the file system, it is possible to use advanced source management tools outside of Ignition to track changes in projects, such as: B. Git Changes made in Ignition Designer are updated in the file system. Ignition also continuously monitors the file system for changes and reads them automatically.

Projects can also be imported and exported via a file (.zip extension) and moved from gateway to gateway using EAM.

We recommend using an external resource management tool to track project changes, e.g. B. Git. You can turn a project folder into a repository and use tools to push changes from development to testing in production environments outside of Ignition.

Change title overview

Deployment environments

Now that we have a good idea of ​​how Ignition configuration is stored and run, let's take a closer look at each environment to see which deployment methods are most efficient in each environment. In the reference architecture below, you can see all three separate Ignition environments (dev, test, and produce), along with Ignition's EAM module and a version control system like GitLab.

environment

Development

The development environment (dev) is the environment where active ignition development takes place. This environment is the first step in the workflow. This is where developers work on bug fixes and new features before rolling out to a production environment. It is very useful to have a separate branch called "Development" in your source control system, which represents your development environment.

There are two main reasons to access a development environment: using a shared development environment or using individual workstations as their own development environment. In a shared development environment, you have a central Ignition server for development, where all developers work. A custom development environment is one where every developer has installed Ignition with their project branch on their workstation. Each approach has advantages and disadvantages. Ignition supports co-development and most users typically use a common development environment, so nothing needs to be installed on each developer's workstation. You can easily run the designer from the development server. If the custom development environment is chosen, each development workstation must individually configure its own Ignition Gateway. Regardless of the approach, changes must be committed to the source control repository and deployed through the workflow.

This, of course, raises some real questions that need to be addressed.

Do I need to license development and test environments?
No. You may only use an Ignition trial license for development and test environments. Some users choose to purchase licenses for these environments to avoid having to reset every two hours. Your choise.

What are the ignition configuration differences for each environment?
It is extremely important to understand the differences in inflammation in each environment. They cannot be exactly the same. The production environment interacts with live data sources such as devices, SQL databases, and more. Maybe you don't want your dev and test environments connected to the same live data sources. You can also have different authentication sources or authorization models in development and test environments. Here's a small list of common differences:

• Devices or PLC connections: Using native Ignition drivers
• OPC UA connections: Direct connection to a third party such as Kepware or PLC
• Database Connections: Connection to an SQL database such as MySQL or MS SQL
• Authentication profiles: different authentication sources or specifically a different admin or root password. Sometimes in a production environment you want to block access to Designer and Gateway.
• Alarm notification profiles: links to email, SMS or voice
• Inventory settings: There is often inventory in production, not in development or testing.

We recommend keeping the same connections in each environment, but with different IP addresses or behind the scenes settings. That way, any resources that rely on knowing the name will continue to work in any environment. For example, you can have a separate SQL database for each environment. All 3 Ignition Gateways share the same database connection by name, but point to their dedicated SQL database which can be local or remote. Screens or named queries that use this connection work in all environments because they refer to the connection by name.

Document these differences to ensure you don't make a production change that affects a development or test system.

How can I simulate real device data during development and testing?
This is a common question because you want access to live data in all environments. Sometimes there are limitations or performance issues that need to be understood. For example, some SPSs do not support more than one connection or would become overloaded with multiple Ignition servers requesting the same tags multiple times. There are several ways to access the actual data:

• OPC UA: Via OPC UA you link your development and test environment to your production environment. The development environment would have the same OPC server name, but would refer to production instead of itself. Be careful as development and testing can affect production, especially when writing to tags.
• MQTT: This is the recommended method for live data transfer to all environments. Ignition's MQTT broadcast module allows you to set up your production environment to publish all tag data to a central MQTT server. All three environments can be subscribed using Ignition's MQTT Engine module and tags are automatically recognized. Each environment can be subscribed without affecting the others. Again, be careful as you may be writing to active PLCs. MQTT servers have Access Control Lists (ACLs) that you can define to make development and test environments read-only if necessary.
• Gateway Network: You can connect your development and test environment to your production environment through Ignition's gateway network and set up third-party tag providers. The development environment would have the same tag vendor name, but would refer to production instead of being local. Again, be careful as you may be writing to active PLCs. Ignition's access network has service-level security to keep dev and test environments read-only when needed. This method is generally not recommended.
• Device Simulation:
  • Programmable Device Simulator: This might be the best option if you don't need live PLC data. Instead, we can use Ignition's programmable device simulator to simulate PLC data. The simulator allows you to define any tag path you want along with static or dynamic values. Your development and test environments use a simulator, while your production environment uses a real PLC. As long as you keep the device name, the labels will be the same on all systems. More information about the simulator can be found in the documentation:https://docs.induktivautomation.com/display/DOC80/Programmable+Device+Simulator
  • SFCs: If you need advanced device simulation, SFCs offer full flexibility. The Programmable Device Simulator provides configurable signals, but the signals do not change based on user actions. SFCs, combined with memory tags, provide a great way to simulate basic PLC functionality such as HOA and valve states, flow, and more.
  • PLC Software Simulator: Many PLC manufacturers offer a software PLC/emulator that can run a real PLC program. If Ignition can communicate with software via OPC, running a real PLC program with all the tags in a system completely separate from the real equipment could be a good option.
• Additional PLCs: If you have a system with a small number of PLCs, it can sometimes make sense to have separate physical PLCs for development and QA environments, especially when PLC programming changes can be introduced at the same time as ignition project changes .

What about custom SQL tables that I want to sync in each environment?
As mentioned earlier, each environment usually has its own dedicated SQL database. You don't want development and testing based on the same database as production. In general, this isn't a problem for Ignition's built-in history, alerts, monitoring, and transaction groups. However, if you create your own custom tables and link Ignition to those tables, we need to think about how to ensure that these tables (structure) and potential data are present in all environments. Traditionally, developers do this manually by executing the same DDL statements (CREATE TABLE, etc.) in all environments. In some cases, there are replication tools or techniques that allow the database system to automate this process. You need to come up with a plan to ensure that all three environments have the same structure and possibly data such as lookup tables.

Test

Once features are implemented and considered to be reasonably stable, they are integrated into the testing branch and then deployed to the testing environment. This is where quality assurance comes in: testers go to the test servers and verify that the project works as intended.

It's very useful to have a separate branch in your source control system called "testing" that represents your testing environment. This allows developers to deploy multiple branches simultaneously on the same server by simply merging everything that needs to be deployed into the test branch. It also helps testers understand what exactly is currently on the test servers just by looking at the test branch.

production

Once a feature has been deployed and tested, it can be deployed to production. A production environment is also known as a live environment, especially for servers, because it is the environment that users interact with directly.

We recommend that you always move major releases into production at a scheduled time that is known by the entire team.

Business Management module

The EAM module provides a secure and intuitive way to manage many ignition installations from one place. It's ideal for large organizations deploying multiple gateways across geographic distances, but even organizations with multiple Ignition Gateways in a single factory can benefit from the ability to monitor performance and automate backup and recovery from a central location.

With the EAM module installed, the Ignition Gateway can act as a central management gateway, connecting to, monitoring, and managing any number of remote agent gateways. Use Controller Gateway to orchestrate and automate many Agent Gateway management tasks, including:

• Check condition and diagnostics
• Assign, update, activate and deactivate licenses
• Offering new and updated modules
• disaster recovery
• Remote backups
• Upgrade for remote ignition

EAM Controller Gateway en best practices

We recommend setting up a dedicated EAM controller gateway or using a development environment as the controller. It is recommended to use EAM for health and diagnostics, licensing, backup and disaster recovery, and upgrades. EAM offers the possibility to move projects and tags from one environment to another. You can use EAM to move tags from one environment to another. However, it is not recommended to use EAM to move projects as this is best handled through a version control system.

resource control system

A source control system is a version control system designed to track changes to source code and other text files during the development of software such as Ignition. This allows the user to retrieve all previous versions of the original source code and saved changes. Version control systems offer many advantages:

• Maintain multiple versions of code
• How to go back to a previous version
• Developers can work in parallel
• Audit traceability with a clear view of who, what, when, where and what the changes are
• Synchronize the code
• Copy/Merge/Undo changes
• Discover the difference between the versions
• It provides a complete backup without taking up much space
• Check the change history
• Suitable for small and large projects
• Ability to share and work on code worldwide

There are many version control systems and we recommend using the one that works best for you. GitLab and Git are very popular open source operating systems.

Resource control and ignition

We recommend storing all Ignition resources in a source control system, including projects, tag exports, images, and gateway backups. Projects are best managed through a version control system because they are stored in a file system. It is extremely easy to push and pull projects in and out of the version control system. However, it is important to define a process for storing and serving tags, images, and gateway configurations, as they are stored in Ignition's internal SQLite database, not individual files.

Getting started with a version control system is extremely easy. We recommend that you install a version control system on a dedicated server or VM, or use an existing version control system that your organization already has. Just set up a project in the source control system for each individual Ignition production environment.

branches of the project

A branch is a working tree version of a project. You create a branch for each set of related changes you make. This keeps each set of changes separate, allowing changes to be made in parallel without affecting each other.

After committing your changes to a branch, you can:

• Create a merge request to merge changes from one branch to another
• Run the inline code review and review the changes
• Discuss implementation with your team

Since we have three separate environments in our workflow, it's a good idea to set up three separate branches for each project:

• Master: The main branch used for production
• Testing: The branch used for testing. There is no development in this branch, but changes are merged from development to QA testing.
• Development: The branch used for active development

Now that we've set up our project and branches, let's define how we're going to push our changes to the repository.

Submit and apply changes

Active development takes place in the development environment. Once the features are deployed and considered to be fairly stable, it's time to include them in the testing branch and then deploy them to the testing environment. We recommend storing your entire Ignition configuration in a repository. Let's go through each configuration item described above: projects, tags, images, and gateway configuration.

project

Projects are stored in a file system, making them easy to transfer to a version control system. Simply create the Ignition project folder as a repository. You can find the project folder on the Ignition server in the following location:

Linux

/var/lib/ignition/data/projects

ramen

C:\Programs\Inductive Automation\Ignition\data\projects

If the repository in the version control system is empty, just upload the existing folder to the repository. If there are no projects in the development system, just get the repository from the server to add the projects.

Anyway, ignore it.Sourcesfolder in your repository. You don't want this directory hard-coded in the repository, as it is unique to each system. See an example below.

When making changes, use the appropriate tools (GUIs, command line tools like Git) to push the changes from the development environment to the repository.

When we are ready to apply the changes for testing, we can merge the changes from development to testing and pull the changes from the repository to the project folder on the testing server.

See the GitLab example below for more details.

keywords

Tags are stored in Ignition's internal SQLite database, so they don't exist as files that we can commit to a repository. However, we can export the tags to a file. There are two methods of saving tags to the source control system: manual export or automatic use of an Ignition Python script to save the file to the repository.

The manual method allows a developer to export the tags to a JSON file in Ignition Designer and save the file to the project folder above when they are ready to commit their changes to the repository. This method allows us to export only when needed instead of doing it automatically every time we save in the designer.

The automatic method, on the other hand, allows us to add a python script to the "Update" gateway event script that runs on every designer save to export the tags to a JSON file and save the file to the project folder. It really is the best method. See the GitLab sample below for more information about the script.

Regardless of the method, it is important to commit changes to the repository to keep track of changes from version to version. We recommend that you save the tags.json file to the following location:

/data/projects/tags.json

When burned, the file is ignored.

When we are ready to commit the changes to testing, we can merge the changes from development to testing and use Ignition's EAM module to commit the tag changes or import the tags to the testing server in the designer.

If you are using the EAM module to make tag changes, see this page for more information:

https://docs.induktivautomation.com/display/DOC80/EAM+in+the+Designer#EAMintheDesigner-TagDistributionforDevelopmentServers

Such an

Images are stored in Ignition's internal SQLite database, so they don't exist as files that we can commit to a repository. However, we can export images to a folder. Here the developer can export the images in the image manager in Ignition Designer to a folder in the project directory when they are ready to make changes to the repository. Make sure you have selected all images and folders in the image manager. We recommend creating a ".images" directory in the project directory and saving the images in the newly created directory:

/podaci/projekti/.slike

In general, you don't want to create folders in the project directory because the gateway assumes that every folder is a project. However, the gateway ignores any hidden folders or folders that begin with ".". Character.

When we are ready to apply the changes to testing, we can merge the changes from development to testing and import the images to the testing server in the designer.

Gateway configuration

The gateway configuration is stored in Ignition's internal SQLite database and has no export and import capabilities. With this in mind, we recommend storing the latest gateway backup (.gwbk) in the repository. Here the developer can save a backup copy of the gateway to the gateway configuration web page when he is ready to commit his changes to the repository.

We recommend creating another hidden folder in the project folder to store the most recent gateway backup, similar to how images are stored in the previous section. Name this new folder ".gateway_backups":

/data/projects/.gateway_backups/Ignition-backup-XXXXXXXX-XXXX.gwbk

When we're ready to apply the changes to testing, we can merge the changes from development to testingmanualMake the necessary gateway configuration changes on the testing server.

Define your workflow and process

You need to define your own workflow and process that everyone can understand. Make sure you answer all the questions above. Document the process and give each developer a cheat sheet. We also recommend creating a post-deployment checklist to ensure accuracy.

GitLab example

1. Install GitLab
   Follow the instructions below to install GitLab on a central server or VM:
   https://about.gitlab.com/install/
   
2. Set your root password
   Use this root user if you use Git
   
3. Generate a personal access token
   Follow the instructions below to create an auto-publish token:
   https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html
   Be sure to check all areas.
   
4. Set up a new project (repository).
   On the dashboard, create a new project with the desired name. The project is empty by default.
   
5. Set up a production environment
   Let's assume that your production environment is already provisioned. You can just install the Git command-line tools and publish your projects to the repository.

   Install the Git command-line tools
   ramen
   https://git-scm.com/download/win

   Linux

   sudo apt-get install git

   
   Identify yourself in Git
   Run the following commands:
   

   git config --global user.name „IhrBenutzername“git config --global user.email „your@email.addr“

   
   Publish projects to the repository
   Navigate to the following folder:
   

   /data/projects

   
   First add a .gitignore file to override the .resources folder.
   

   nano .gitignore

   
   Add the following line to your .gitignore file:
   

   .Sources/

   
   Save the file. Now run the following commands to initialize and commit the repository:
   

   git initgit remote add source http(s)://root:TOKEN@URL/root/PROJECT.gitgit add .git commit -m "Initial commit" git push -u origin master

   
   After the first commit, set the branch as master for future pushes.
   

   git grana --set-upstream-to=origin/master

   
   We have now successfully completed our projects. We also need to export and validate tags, images, and gateway configuration. For tags, we can export the tags from the designer to the tags.json file. For images, we can use the image management tool in the designer to export all images to a folder called "images". To configure the gateway, simply backup the gateway. Take all files and folders and save them in the project directory. Once added, use the following commands to push them to the repository:
   

   NOW=$(datum +"%m-%d-%Y %H:%M:%S")git add .git commit -m "Designer save @ $NOW"git push origin

   
   Adjust the above script for Windows. Now everything is stored in the repository.
   
6. Create development and test branches
   Use the web interface to create development and testing branches of the main branch. They will automatically commit everything to the master branch. Follow these instructions:
   https://docs.gitlab.com/ee/gitlab-basics/create-branch.html
   
7. Development and test setup
   Install Ignition on dedicated dev and test machines or VMs. Follow the instructions above to install Git. After installing Git, navigate to the following folder:
   

   /facts

   
   Delete the existing project folder. It is empty because it is a clean install. Once removed, run the following commands from that directory:
   

   Git-Klon http(s)://root:TOKEN@URL/root/PROJECT.git-Projekte

   
   Now navigate to the project folder that will be recreated. Run the following commands to switch to the development or testing branch:
   

   git checkout razvoj git grana --set-upstream-to=origin/development

   
   Replace "development" above with "testing" for the test branch on the test server.

   Finally, we need to make sure that the tags and images are imported into the designer. You can import tags using EAM or manually import them into the designer. We also have to manually build all gateway configurations, for example create a database or device connection, set up authentication profiles and more. Unfortunately, this is a manual step, but it's important to monitor changes in these areas.
   

8. Automatically apply development changes
   Now that we've set up the development environment and pulled projects from the development branch, we need to set up Ignition to automatically apply changes when a developer presses save in Ignition Designer.

   First we need to create a batch/shell script called "git-auto-commit.sh" or "git-auto-commit.bat" in the data directory, for example on Linux:
   

   /var/lib/ignition/data/git-auto-commit.sh

   
   The file contains the following lines:
   

   cd /var/lib/ignition/data/projectsNOW=$(datum +"%m-%d-%Y %H:%M:%S")git add .git commit -m "Designer save @ $NOW"git Push-Ursprung

   
   Adjust the above script for Windows. Make sure the file has executable permissions. Then we need to call this script every time the developer clicks save in the designer. Open Ignition Designer and select Project > Gateway Events > Refresh. See the documentation for more details:

   https://docs.induktivautomation.com/display/DOC80/Gateway+Event+Scripts#GatewayEventScripts-UpdateScript

   Add the following script:
   

   importeer timetime.sleep(5)system.util.execute(["/var/lib/ignition/data/git-auto-commit.sh"])

   
   The script calls a batch/shell script and writes the changes to the repository each time you save. Save the project and view the repository in GitLab to see the commit.
   
9. Anchors tags automatically
   It can be useful to automatically export and save tags to the repository as part of the save process. To do this, simply modify the Gateway Event Update script as follows:
   

   import timefilePath = "/var/lib/ignition/data/projects/tags.json" system.tag.exportTags(filePath=filePath, tagPaths=["[standaard]"])time.sleep(5)system.util.execute (["/var/lib/ignition/data/git-auto-commit.sh"])

   
   Adjust the tag paths to include all tag providers you want to export. Tags are exported each time you save them and stored in a file called tags.json in the project directory. Commit happens after export, so the file is committed to the repository.
   
10. Implement the changes
    After we finish development, we need to apply the changes in the test environment. First, we need to merge the changes from the development branch with the testing branch within GitLab. Open the UI and create a merge request from the development branch to the test branch. By default, the master branch is selected. So make sure you change this in the test branch.Make sure to uncheck the "Delete source branch" box so you don't delete the development branch.See the GitLab documentation for more details:
    https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html

    After the merge request is created, you must approve the request and actually merge the changes for testing. Once the changes are merged, we need to deploy our changes to Ignition on the test server.
    

    (Video) New Visualization Tools in Ignition
    1. Execute projects
       For projects, we just need to get the changes from the repository. Run the following command on the testing server:
       

       Draw git

       
       After applying the changes, Ignition will automatically update the project resources. Customers are updated automatically. If you've already opened Ignition Designer, you'll need to click File > Create Project to get these changes from the server.
       
    2. Implement tags
       The tags.json export file is retrieved from the previous step. You can manually import tags into tests or use EAM to make tag changes.
       
    3. providing images
       The images are retrieved from the repository from the previous step. You must manually import images into the Image Manager in Ignition Designer.
       
    4. Set up the gateway configuration
       Any gateway configuration changes must be manually applied to the test environment. This includes changing settings, adding database connections, adding device connections, and more. This is probably the hardest part of making changes from development to testing and testing to production. DO NOT restore a gateway backup when deploying for test or production purposes as each environment is different.