Getting Started
Core Concept
When installation files or update packages need to be distributed to multiple servers and branches, you can operate by connecting directly to each target server or storing files on shared storage and preparing the installation files individually.
However, as the number of deployment targets increases, the work of checking which package version was deployed to which server, whether deployment to a specific branch is complete, and which targets failed can also increase.
With INNORIX Flow, centrally prepared installation files and update packages can be transferred to multiple servers and remote branches, and file reflection results for each target can be checked in a single flow.
Package Repository
│
▼
Distribution Flow
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Server A Server B Server C
│ │ │
▼ ▼ ▼
Branch A Branch B Branch C
This configuration enables a software distribution flow that connects package preparation → target selection → transfer to each target → file reflection → distribution result check → failed-target response.
Deployment Targets
The same software package can be transferred to every target, but in real environments, different packages may need to be deployed depending on the server role or operating location.
For example, an installer can be transferred to Windows servers, a compressed deployment file to Linux servers, and an update package together with configuration files to a specific branch.
Software Packages
│
├── Application
│ ├── application.exe
│ └── application.tar.gz
│
├── Update
│ └── update-package.zip
│
└── Configuration
└── config.json
| Package Type | Use Case |
|---|---|
| Installation File | Install programs on new servers and devices |
| Update Package | Update the version of an existing system |
| Configuration File | Configure environments for servers or branches |
| Binary | Distribute application executable files |
| Compressed Package | Distribute multiple configuration files as a single package |
By configuring deployment targets based on file types and target environments, you can manage software distribution tasks consisting of multiple files as well as a single package.
Distribution Method
Packages can be distributed to multiple targets by transferring them to all targets simultaneously or by deploying them incrementally in a defined order.
For example, you can first transfer an update package to test servers, verify the result, and then deploy it to production servers and remote branches.
Package Ready
│
▼
Test Servers
│
▼
Result Check
│
├── Success ──────► Production Servers
│
└── Check ────────► Review
Conversely, when the same package must be deployed to multiple branches, files can be distributed from one Source to multiple Targets.
| Distribution Method | Use Case |
|---|---|
| Simultaneous Deployment | Deploy the same package to multiple targets |
| Sequential Deployment | Run the next target after checking the previous target's result |
| Staged Deployment | Separate test and production environments for deployment |
| Per-Target Deployment | Apply different packages to each server or branch |
| Conditional Deployment | Determine the next deployment based on the previous task's result |
This allows targets and execution order to be separated according to the actual deployment policy instead of transferring files to every server and branch in the same way.
IT Engineer
Package Preparation
Before starting the deployment task, connect the location where installation files or update packages are generated as the Source.
The Source can be configured based on the environment where actual deployment files are prepared, such as a central file server, build server, or package repository.
Package Source
│
├── /release/
│ ├── app-v2.4.zip
│ └── update-v2.4.zip
│
└── /config/
└── production.json
When configuring the Source, you can check the following items together.
| Configuration Item | Settings |
|---|---|
| Package Location | Paths to installation and update files |
| File Selection | Files and folders to actually deploy |
| Version | Software version to deploy |
| File Conditions | Specific extensions or file name criteria |
| Access Scope | Permissions to read deployment files |
For example, when a new version of a package is generated at /release/latest, you can configure it to transfer that file to multiple deployment targets.
Target Configuration
Configure each server and branch receiving the package as a Target.
The targets do not need to be the same type of server; they can be configured according to the environments where files are actually reflected, including Windows servers, Linux servers, and remote file servers.
Distribution Targets
│
┌────────────────┼────────────────┐
▼ ▼ ▼
Seoul Office Busan Office Data Center
│ │ │
▼ ▼ ▼
Windows Linux File Server
Different storage paths can also be used for each target.
| Target | Example Storage Location |
|---|---|
| Windows Server | C:\Deploy\Package\ |
| Linux Server | /opt/deploy/package/ |
| Remote Branch Server | /data/update/ |
| File Server | /share/software/ |
This allows the actual file location to be managed according to each target environment even when one package is transferred to multiple targets.
Deployment Flow
By connecting a Source to multiple Targets, you can distribute a single software package to multiple servers and branches.
The same package can be transferred to multiple targets simultaneously or deployed in a defined order by group.
Software Package
│
▼
Distribution Flow
│
┌────────────┼────────────┐
▼ ▼ ▼
Server Group Branch Group Archive
│ │
┌───┴───┐ ┌───┴───┐
▼ ▼ ▼ ▼
Server 1 Server 2 Site A Site B
The deployment structure can be configured as follows.
| Configuration | Use Method |
|---|---|
| Full Deployment | Transfer one package to all targets |
| Group Deployment | Separate servers and branches into groups |
| Sequential Deployment | Run the next group after the previous target is complete |
| Parallel Deployment | Transfer to multiple targets simultaneously |
| Version-Based Deployment | Transfer different packages to each target |
This allows multiple targets to be managed within a single deployment flow instead of configuring separate transfer tasks for each server as the number of targets grows.
Execution Conditions
Package deployment can be started manually by an operator or configured to start automatically when a new version of a file is ready or when the previous task is completed.
Distribution Trigger
│
┌────────────────┼────────────────┐
▼ ▼ ▼
New Package Scheduled Previous Flow
│ │ │
└────────────────┼────────────────┘
▼
Distribution Run
[Product UI screen for executing a deployment task based on conditions such as creation of a new package, a specified time, and completion of the previous task]
| Execution Condition | Use Method |
|---|---|
| New File Created | Automatically deploy after a new package is prepared |
| Date/Time | Deploy on a scheduled basis at the specified time |
| After Transfer | Start the next deployment after the previous task is complete |
| URL Request | Run according to an external deployment request |
| Manual Run | Run manually when the operator needs to |
For example, after a new package version is generated on the build server, you can first transfer it to the test server and then deploy it to production servers and remote branches after verification is complete.
Per-Target Check
When deploying to multiple servers and branches, it is necessary not only to check that the overall task is complete, but also to verify that the package has been successfully reflected on each target.
In Runs, you can check the status of the overall deployment task and, in the details, check the processing result and file transfer status for each target.
Distribution Run
│
├── Server Group A
│ ├── Server 01 ✓ Completed
│ └── Server 02 ✓ Completed
│
├── Branch Group B
│ ├── Branch 01 ✓ Completed
│ └── Branch 02 ! Check Required
│
└── Branch Group C
└── Branch 03 ○ In Progress
The per-target results provide the following information.
| Check Item | Details |
|---|---|
| Target | Server or branch to which the package was transferred |
| Target Path | File storage location on the target system |
| Package | Deployed installation file or update package |
| Total Files | Number of files transferred |
| Total Size | Total package size |
| Progress | Current transfer progress |
| Status | Deployment status for the target |
| Completed | Task completion time for the target |
This allows you to focus on the results of the affected target even when the overall deployment task is complete but some targets require additional review.
Follow-up Tasks
After the package file has been successfully reflected on the target server or branch, you can connect the next task.
For example, you can run an installation task after the installation file transfer is complete, or connect a task to check the results after an update package has been deployed to all targets.
Package Transfer
│
▼
Target Verification
│
├── Success ────► Next Task
│ │
│ ├── Installation
│ ├── Update
│ └── Notification
│
└── Check ──────► Review
Follow-up tasks can be connected differently depending on the deployment result.
| Deployment Result | Next Task |
|---|---|
| All Targets Complete | Run installation or update tasks |
| Some Targets Complete | Check the results for completed targets |
| Specific Target Requires Review | Check the status of the corresponding server or branch |
| All Files Reflected | Notify the responsible person or operating environment |
| Redistribution Required | Rerun the task for the required targets |
This creates a flow that goes beyond transferring package files to multiple servers and continues through installation, updates, and operational checks based on the file reflection results.
Exception Handling
If a package is not successfully deployed to a specific server or branch, you can check the Run details for the affected target instead of rerunning the entire deployment task from the beginning.
For example, if an update package is successfully reflected on other servers but there is a problem with the connection status or Target path of a specific branch, check the target's connection environment and file processing results.
Distribution Run
│
▼
Target Status Review
│
┌─────┼───────────────┐
▼ ▼ ▼
A ✓ B ! C ✓
│
▼
View Details
│
┌─────┼───────────────┐
▼ ▼ ▼
Connection Target Path Permission
│
└───────┬────────┘
▼
Adjust
│
▼
Retry
│
▼
Package Verified
If a problem occurs, you can check the following items together.
| Check Item | Details | Follow-up Action |
|---|---|---|
| Target Connection | Connection status of the server or branch | Check the connection environment |
| Target Path | Location where the package is stored | Adjust the path |
| Access Permissions | Whether files can be stored | Check permission settings |
| File Status | Transfer result for each package | Check the file status |
| Package Information | Version and files for the deployment target | Check the version |
| Execution History | Run and per-target processing results | Rerun the required task |
After the problem is resolved, instead of redistributing the same package to all servers and branches, you can rerun the task for the targets requiring attention and the relevant files.
Through this process, you can build a software package distribution flow that connects package preparation → deployment target configuration → Target connections for each server and branch → execution condition configuration → parallel or staged deployment → per-target result checks → follow-up task connections → exception-target response.
Even when distributing installation files and update packages to multiple servers and remote branches, managing file transfers and per-target processing results centrally based on a single Flow can reduce the work of checking deployment status individually in each environment and connect follow-up actions for the targets that need them.