{{short description|Activities that make a software system available for use}} {{Use American English|date=June 2020}}
'''Software deployment''' is all of the activities that make a software system available for use.<ref>{{Cite book |last=Pressman |first=Roger S. |title=Software Engineering: A Practitioner's Approach |edition=8th |publisher=McGraw-Hill |year=2014 |isbn=978-0078022128}}</ref><ref>{{Cite web |title=Deploying software |url=https://www.ibm.com/docs/en/zos/3.1.0?topic=task-deploying-software |access-date=25 November 2024 |website=IBM Documentation |publisher=IBM |language=en-us}}</ref>
Deployment can involve activities on the producer (software developer) side or on the consumer (user) side or both. Deployment to consumers is a hard task because the target systems are diverse and unpredictable.<ref>A. Nejati, M. Svechikov, J. Wuttke: Deploying a C++ Software with (or without) Python Embedding and Extension. In: deRSE24 - Selected Contributions of the 4th Conference for Research Software Engineering in Germany, edited by J. Bernoth et al. Electronic Communications of the EASST, vol 83 (2025). https://eceasst.org/index.php/eceasst/article/view/2596.</ref><ref>{{Cite web |title=What Is Software Deployment? |url=https://www.pagerduty.com/resources/continuous-integration-delivery/learn/what-is-software-deployment/ |access-date=23 September 2025 |website=PagerDuty}}</ref> Software as a service avoids these difficulties by deploying only to dedicated servers that are typically under the producer's control.
Because every software system is unique, the precise processes or procedures within each activity can hardly be defined. Therefore, "deployment" should be interpreted as a ''general process'' that has to be customized according to specific requirements or characteristics.<ref>{{ cite web | url = https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-ansible-on-ubuntu-18-04 | title = How to Install and Configure Ansible on Ubuntu 18.04 | access-date = 8 June 2019 | first = Stephen | last = Rees-Carter | date = 13 July 2018 | website = DigitalOcean | quote = Configuration management systems are designed to make controlling large numbers of servers easy for administrators and operations teams. They allow you to control many different systems in an automated way from one central location. | archive-url = https://web.archive.org/web/20190609015846/https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-ansible-on-ubuntu-18-04 | archive-date = 9 June 2019 | df = dmy-all }}</ref>
== History == When computers were extremely large, expensive, and bulky (mainframes and minicomputers), the software was often bundled together with the hardware by manufacturers and provided for free.<ref>{{Cite web |title=Software Becomes a Product |url=https://www.computerhistory.org/revolution/mainframe-computers/7/172 |access-date=23 September 2025 |website=Computer History Museum}}</ref> A pivotal moment occurred in 1969 when IBM, influenced by antitrust lawsuits, began charging for software and services separately from hardware. This "unbundling" effectively created the modern software industry, turning software into a commercial product.<ref>{{Cite web |title=Software Becomes a Product |url=https://www.computerhistory.org/revolution/mainframe-computers/7/172 |access-date=23 September 2025 |website=Computer History Museum}}</ref> Early deployment processes were highly structured; the Lincoln Labs Phased Model, developed in 1956 for the SAGE air defense system, introduced sequential phases that influenced later methodologies.<ref>{{Cite web |title=Early Software Delivery Models |url=https://octopus.com/devops/history/early-software-delivery-models/ |access-date=23 September 2025 |website=Octopus Deploy |date=August 23, 2022}}</ref> This approach was formalized in the waterfall model, which became dominant after being described by Winston Royce in 1970. It led to infrequent, costly, and lengthy release cycles, often taking years.<ref>{{Cite web |title=Early Software Delivery Models |url=https://octopus.com/devops/history/early-software-delivery-models/ |access-date=23 September 2025 |website=Octopus Deploy |date=August 23, 2022}}</ref> If business software needed to be installed, it often required an expensive, time-consuming visit by a systems architect or a consultant.<ref>{{Cite web |title=Early Software Delivery Models |url=https://octopus.com/devops/history/early-software-delivery-models/ |access-date=23 September 2025 |website=Octopus Deploy |date=August 23, 2022}}</ref> For complex, on-premises installation of enterprise software today, this is sometimes still the case.<ref>{{Cite web |last=Bansal |first=Prateek |title=The Evolution of Software Deployment: From Physical Servers to Container Orchestration |url=https://medium.com/@prateekbansalind/the-evolution-of-software-deployment-from-physical-servers-to-container-orchestration-8610e9389198 |access-date=23 September 2025 |website=Medium |date=August 22, 2023}}</ref>
The development of mass-market software for the new age of microcomputers in the 1980s brought new forms of software distribution{{spaced endash}}first cartridges, then Compact Cassettes, then floppy disks, and later (in the 1990s and beyond) optical media, the internet and flash drives.<ref>{{Cite web |last=Oosthuizen |first=Dewald |title=The Evolution of Software Development |url=https://medium.com/dvt-engineering/the-evolution-of-software-development-7c3d70de8775 |access-date=23 September 2025 |website=Medium |date=May 15, 2025}}</ref><ref>{{Cite web |title=The Evolution of Software Development! |url=https://xpartron.com/the-evolution-of-software-development/ |access-date=23 September 2025 |website=XPARTRON |date=September 11, 2024}}</ref> This shift meant that software deployment could be left to the customer.<ref>{{Cite web |last=Poornima |title=A Short History of Deployment Processes |url=https://poornima.hashnode.dev/a-short-history-of-deployment-processes |access-date=23 September 2025 |website=Hashnode |date=August 18, 2023}}</ref> During this period, alternatives to the rigid waterfall model emerged. The Spiral Model, proposed by Barry Boehm in 1988, introduced a risk-driven, iterative approach that challenged waterfall's linear structure and paved the way for more flexible, agile methodologies.<ref>{{Cite web |title=Early Software Delivery Models |url=https://octopus.com/devops/history/early-software-delivery-models/ |access-date=23 September 2025 |website=Octopus Deploy |date=August 23, 2022}}</ref> As customer-led deployment became standard, it was recognized that configuration should be user-friendly. In the 1990s, tools like InstallShield became popular, providing installer wizards that eliminated the need for users to perform complex tasks like editing registry entries.<ref>{{Cite web |title=The Evolution of App Deployment and Packaging: 1990 to Now |url=https://blog.iron.io/the-evolution-of-app-deployment-and-packaging-1990-to-now/ |access-date=23 September 2025 |website=Iron.io Blog |date=December 23, 2020}}</ref>
In pre-internet software deployments, releases were by nature expensive and infrequent affairs.<ref>{{Cite web |title=Early Software Delivery Models |url=https://octopus.com/devops/history/early-software-delivery-models/ |access-date=23 September 2025 |website=Octopus Deploy |date=August 23, 2022}}</ref> The spread of the internet fundamentally transformed software distribution and made end-to-end agile software development viable by enabling rapid collaboration and digital delivery.<ref>{{Cite journal |last=Wasserman |first=Anthony I. |title=How the Internet transformed the software industry |url=https://www.researchgate.net/publication/220066355 |access-date=23 September 2025 |journal=J Internet Serv Appl |year=2011 |volume=2 |pages=11–22 |doi=10.1007/s13174-011-0019-x|doi-access=free }}</ref> The foundations for modern rapid deployment were laid in the 1990s when Kent Beck developed Continuous Integration as a core practice of Extreme Programming, advocating for developers to integrate their work daily.<ref>{{Cite web |last=Fowler |first=Martin |title=Continuous Integration |url=https://martinfowler.com/articles/continuousIntegration.html |access-date=23 September 2025 |website=martinfowler.com |date=January 18, 2024}}</ref> The advent of cloud computing and software as a service (SaaS) in the 2000s further accelerated this trend, allowing software to be deployed to a large number of customers in minutes. This shift also meant deployment schedules were now typically determined by the software supplier, not the customers.<ref>{{Cite web |title=Continuous Delivery: Origins, 5 Principles, And 7 Key Capabilities |url=https://octopus.com/devops/continuous-delivery/ |access-date=23 September 2025 |website=Octopus Deploy |date=July 20, 2022}}</ref><ref>{{Cite journal |last=Wasserman |first=Anthony I. |title=How the Internet transformed the software industry |url=https://www.researchgate.net/publication/220066355 |access-date=23 September 2025 |journal=J Internet Serv Appl |year=2011 |volume=2 |pages=11–22 |doi=10.1007/s13174-011-0019-x|doi-access=free }}</ref> Such flexibility led to the rise of continuous delivery as a viable option, especially for web applications.<ref>{{Cite web |last=Fowler |first=Martin |title=Continuous Integration |url=https://martinfowler.com/articles/continuousIntegration.html |access-date=23 September 2025 |website=martinfowler.com |date=January 18, 2024}}</ref>
Modern deployment strategies that build upon these principles include blue–green deployment and canary release deployment.<ref>{{Cite web |title=A Brief History of DevOps, Part IV: Continuous Delivery vs. Continuous Deployment |url=https://circleci.com/blog/a-brief-history-of-devops-part-iv-continuous-delivery-and-continuous-deployment/ |access-date=23 September 2025 |website=CircleCI Blog |date=November 9, 2023}}</ref>
== Deployment activities == ; Release: The release activity follows from the completed the development process and is sometimes classified as part of the development process rather than deployment process.<ref>{{Cite conference |last1=Dolstra |first1=Eelco |last2=Jonker |first2=Willem |last3=Löwe |first3=Erik |title=Integrating Software Construction and Software Deployment |book-title=Proceedings of the 3rd workshop on Software configuration management |year=2003 |url=https://edolstra.github.io/pubs/iscsd-scm11-final.pdf}}</ref> It includes all the operations to prepare a system for assembly and transfer to the computer system(s) on which it will be run in production. Therefore, it sometimes involves determining the resources required for the system to operate with tolerable performance and planning and/or documenting subsequent activities of the deployment process. ; Installation and activation: For simple systems, installation involves establishing some form of a command, shortcut, script or service for executing the software (manually or automatically). For complex systems it may involve configuration of the system{{spaced endash}} possibly by asking the end-user questions about its intended use, or directly asking them how they would like it to be configured{{spaced endash}} and/or making all the required subsystems ready to use. Activation is the activity of starting up the executable component of software for the first time (not to be confused with the common use of the term ''activation'' concerning a software license, which is a function of Digital Rights Management systems.) : In larger software deployments on servers, the main copy of the software to be used by users - "production" - might be installed on a production server in a production environment. Other versions of the deployed software may be installed in a test environment, development environment and disaster recovery environment. : In complex continuous delivery environments and/or software as a service system, differently-configured versions of the system might even exist simultaneously in the production environment for different internal or external customers (this is known as a ''multi-tenant architecture''), or even be gradually rolled out in parallel to different groups of customers, with the possibility of canceling one or more of the parallel deployments. For example, Twitter is known to use the latter approach for A/B testing of new features and user interface changes. A "hidden live" group can also be created within a production environment, consisting of servers that are not yet connected to the production load balancer, for the purposes of blue–green deployment. ; Deactivation: Deactivation is the inverse of activation and refers to shutting down any already-executing components of a system. Deactivation is often required to perform other deployment activities, e.g., a software system may need to be deactivated before an update can be performed. The practice of removing infrequently used or obsolete systems from service is often referred to as application retirement or application decommissioning. ; Uninstallation: Uninstallation is the inverse of installation. It is the removal of a system that is no longer required. It may also involve some reconfiguration of other software systems to remove the uninstalled system's dependencies. ; Update: The update process replaces an earlier version of all or part of a software system with a newer release. It commonly consists of deactivation followed by installation. On some systems, such as on Linux when using the system's package manager, the old version of a software application is typically also uninstalled as an automatic part of the process. (This is because Linux package managers do not typically support installing multiple versions of a software application at the same time unless the software package has been specifically designed to work around this limitation.) ; Built-in update: Mechanisms for installing updates are built into some software systems (or, in the case of some operating systems such as Linux, Android and iOS, into the operating system itself). Automation of these update processes ranges from fully automatic to user-initiated and controlled. Norton Internet Security is an example of a system with a semi-automatic method for retrieving and installing updates to both the antivirus definitions and other components of the system. Other software products provide query mechanisms for determining when updates are available. ; Version tracking: Version tracking systems help the user find and install updates to software systems. For example: The Software Catalog stores the version and other information for each software package installed on a local system. One-click of a button launches a browser window to the upgrade web page for the application, including auto-filling of the user name and password for sites that require a login. On Linux, Android and iOS this process is even easier because a standardized process for version tracking (for software packages installed in the officially supported way) is built into the operating system, so no separate login, download and execute steps are required{{spaced endash}} so the process can be configured to be fully automated. Some third-party software also supports automated version tracking and upgrading for certain Windows software packages.
== Deployment roles ==
The complexity and variability of software products have fostered the emergence of specialized roles for coordinating and engineering the deployment process. For desktop systems, end-users frequently also become the "software deployers" when they install a software package on their machine. The deployment of enterprise software involves many more roles, and those roles typically change as the application progresses from the test (pre-production) to production environments. Typical roles involved in software deployments for enterprise applications may include:<ref>{{Cite book |last1=Bass |first1=Len |last2=Weber |first2=Ingo |last3=Zhu |first3=Liming |title=DevOps: A Software Architect's Perspective |publisher=Addison-Wesley |year=2015 |isbn=978-0134049847}}</ref> * in pre-production environments: ** application developers: see Software development process ** build-and-release engineers: see Release engineering ** release managers: see Release management ** deployment coordinators: see DevOps * in production environments: ** system administrator ** database administrator ** release coordinators: see DevOps ** operations project managers: see ITIL<ref>{{Cite book |last=Steinberg |first=Gene |title=Reinventing ITIL in the Age of DevOps: Innovative Practices Across Frameworks |publisher=Apress |year=2018 }}</ref>
== See also == * Application lifecycle management * Product lifecycle management * Systems management * System deployment * Software release * Definitive Media Library * Readme * Release management *Deployment environment
== References == {{reflist}}
==External links== * Standardization efforts ** [http://www.w3.org/Submission/2004/04/ Solution Installation Schema Submission request to W3C] ** [http://www.oasis-open.org/committees/sdd/charter.php OASIS Solution Deployment Descriptor TC] ** [http://www.info.fundp.ac.be/~ven/CIS/OMG/Deployment%20and%20Configuration%20of%20Component-based%20Distributed%20Applications.pdf OMG Specification for Deployment and Configuration of Component-based Distributed Applications] (OMG D&C) ** [http://jcp.org/en/jsr/detail?id=88 JSR 88: Java EE Application Deployment] * Articles ** {{cite web |last1=Carzaniga |first1=Antonio |last2=Fuggetta |first2=Alfonso |last3=Hall |first3=Richard S. |last4=Van Der Hoek |first4=André |last5=Heimbigner |first5=Dennis |last6=Wolf |first6=Alexander L. |title=A Characterization Framework for Software Deployment Technologies – Technical Report CU-CS-857-98 |publisher=Department of Computer Science, University of Colorado Boulder |location=Boulder, CO |date=April 1998 |url=http://www.cs.colorado.edu/department/publications/reports/docs/CU-CS-857-98.pdf}} * Resources **[https://www.visualstudio.com/en-us/features/release-management-vs.aspx/ Visual Studio Release Management]
{{Software engineering}}
{{DEFAULTSORT:Software Deployment}} Category:Software distribution Category:System administration Category:Software release