Ship, Upload, Apply — the meaning of terms and differences

What does “ship”, “upload”, “apply” mean

“Ship” is the most general term meaning the publication of a new version of a software product, feature, or change. “We shipped an update,” “we shipped a fix,” “we shipped a release” — in all cases, the change becomes available to users. The term implies a fairly large action: you usually ship an entire version, not a single file.

“Upload” is a more specific term meaning the loading of files, data, or artifacts onto a server or storage. “Upload the build to the server,” “upload scripts to the DB,” “upload assets to the CDN.” Unlike “ship,” the term does not imply that the uploaded content has become available to users — files can sit on the server but not be connected to the application. Note: “upload” is also used for sending code to a repository (“uploaded to GitHub”).

“Apply” is a term meaning applying a change on top of an existing version. “Apply a migration,” “apply a patch,” “apply a config.” The key difference is that the change is layered on top without a full replacement. If “ship” means launching a new version instead of the old one, then “apply” means adding a change to what is already working. The term is common in the context of databases (migrations) and patch releases.

Additional terms from the same semantic field: “roll out” (distribute a change across all servers in a cluster), “roll back” (revert to the previous version), “spill” (accidentally deploy the wrong version). All these verbs describe actions with code as if it were a physical object that can be “rolled,” “poured,” and “rolled back.”

Origins of slang terms

The term “ship” comes from an automotive metaphor: “ship a car out of the garage.” When code is ready for release, it gets “shipped” — let out, made available to users. The metaphor spread in the early 2000s with the rise of continuous delivery practices, when releases became regular rather than annual. “We have a ship day today” means release day.

The term “upload” has roots in the early web, when sites were uploaded to servers via FTP. “Upload files to the server” — literally transfer files over a protocol associated with “pouring” data. The word stuck, although modern deployment uses CI/CD pipelines rather than FTP clients. Interesting fact: in English, the analog is “push” (push to server), not “pour.” The Russian language chose a different metaphor.

The term “apply” comes from a production environment: “apply a wheel,” “screw on a nut.” In the context of software — layering a change on top of an existing system, like threading a bolt. In databases the term is especially organic: migrations are “applied” and “rolled back.” Rollback is one of the few English terms that has an exact counterpart in Russian: “otkat.”

Difference between terms in different contexts

In the context of databases: migrations are “applied,” data is “uploaded,” a schema version is “shipped.” If you need to add a new column — apply a migration. If you need to insert test data — upload a dump. If the entire database structure changes — ship a new schema. The difference reflects different operations: apply, insert/load, deploy.

In the context of DevOps: “ship” — run a pipeline, “upload” — push a Docker image to a registry, “apply” — apply a configuration to a server via Ansible. Example: “first we’ll upload the image to the registry, then apply the config to the server, and only then ship the release.” Each term corresponds to a separate stage of the CI/CD pipeline.

In the context of mobile development: “upload” — send a build to App Store Connect or Google Play Console, “ship” — publish in the app store, “apply” — deliver an update via in-app updates mechanism. For iOS, “ship” means passing Review; for Android, rollout via Play Console. Time scale: “upload” takes minutes, “ship” takes hours or days (due to review).

Release process stages: from commit to production

Stage 1: Build. Code is compiled, an artifact is assembled (binary, Docker image, APK/IPA). A CI server runs the build after every commit to the main branch. The build result is a deploy-ready artifact with a unique version tag (semantic versioning or commit hash). If the build fails — the entire pipeline stops, the developer gets a notification.

Stage 2: Test. Unit tests, integration tests, linters, and security checks (SAST) are run. This stage should take no more than 10–15 minutes — if longer, developers lose context and switch to other tasks. Fast feedback is a key CI/CD principle. According to the Puppet State of DevOps 2023, teams with fast testing (<10 min) ship 3 times more releases.

Stage 3: Staging Deploy. The artifact is deployed to a staging environment identical to production. E2E tests, smoke tests, and, if needed, manual QA testing are performed on staging. If a regression is found on staging, the release is blocked and changes are sent back for rework.

Stage 4: Production Deploy. The artifact is deployed to production servers. Depending on the deployment strategy (rolling, blue-green, canary), the rollout can take from seconds to hours. After the rollout, post-deploy tests and monitoring are run — if metrics are normal, the release is considered successful. Automatic rollback when the error threshold is exceeded is standard practice.

Deployment strategies: rolling, blue-green, canary

Rolling deploy — updating servers one by one. While one server is being updated, the rest continue serving users. After the first server is successfully updated, the second is updated, and so on. Downside: during deployment, different versions run on different servers, which can cause incompatibility. Upside: zero-downtime and no need for double the server capacity.

Blue-green deploy — two identical environments: Blue (current version) and Green (new version). After Green is fully ready and tested, the load balancer switches traffic from Blue to Green. If a problem is found on Green — switch back to Blue. Upside: instant rollback. Downside: double the resources (servers) to support two environments. Switching takes seconds.

Canary deploy — the new version is first deployed to a small percentage of servers (5–10%). Some users get the new version, the rest stay on the old one. If metrics on the canary group are normal (error rate hasn’t increased, latency hasn’t grown), the new version is gradually rolled out to all servers. Google, Netflix, Spotify use canary deploy to minimize risks. Downside: complexity of monitoring and metric analysis.

Deployment automation tools

CI/CD servers — Jenkins, GitLab CI, GitHub Actions, CircleCI, Bitrise (for mobile). They are chosen depending on the stack: Jenkins is universal, GitLab CI if the repository is on GitLab, Bitrise for iOS/Android. The main task of a CI/CD server is to automatically execute the build, test, and deployment pipeline without human intervention.

Containerization — Docker, Kubernetes. Docker creates isolated containers with the application and all dependencies. Kubernetes manages container deployment across a server cluster: automatic rolling update, scaling, load balancing. According to the CNCF Survey 2023, 96% of organizations use containers in production, of which 67% use Kubernetes.

Infrastructure as Code — Terraform, Ansible, Pulumi. Terraform describes infrastructure (servers, networks, load balancers) as code and manages its state. Ansible handles server configuration: installing software, setting parameters. The Terraform + Ansible combination provides fully automated infrastructure: Terraform provisions servers, Ansible configures them. Immutable infrastructure — servers are not updated, but replaced with new ones running an updated image.