An in-place upgrade updates software on existing target machines instead of replacing them. The machines keep running while an agent applies the change, making this approach useful when deployment speed matters or when applications persist state locally, such as database-like systems storing data on disk. section 15.1
AWS CodeDeploy automates this workflow for EC2. An engineer uploads a revision containing application files and deployment instructions, selects a target group, and starts a deployment. The CodeDeploy agent on each instance downloads the archive from Amazon S3, runs its instructions, copies the files, and reports status. section 15.1
A CodeDeploy in-place deployment is organized around these components:
- Application: names the deployment and identifies its compute platform. section 15.1
- Deployment group: identifies the target instances, such as an Auto Scaling group. section 15.1
- Revision: references the deployable code stored in Amazon S3 or GitHub. section 15.1
- Deployment: rolls a selected revision out to the target group. section 15.1
The AppSpec file controls the instance-side procedure. It maps files to destinations and attaches scripts to lifecycle hooks such as BeforeInstall, AfterInstall, ApplicationStart, and ValidateService. Deployment configurations can update all targets, half at a time, or one at a time.
Deploying Etherpad
A practical setup uses an Application Load Balancer, an Auto Scaling group, and an RDS database. Upload a packaged revision to S3, then create a deployment with AWS CLI commands such as `aws deploy create-deployment` using the application name, deployment group, and S3 revision. A later application version is uploaded and deployed the same way.
In-place deployment is fast and works with stateful machines, but successive changes can accumulate and make deployments difficult to reproduce. Compared with launching new machines through CloudFormation or immutable AMIs through Packer, it trades replacement-based consistency for speed and retained local state. All three approaches support gradual, zero-downtime rollouts. section 15.4
