9 Software Delivery and Project Practices

Software delivery as a continuing process

Software delivery is a coordinated process that continues after code is written. Changes need to be integrated, released safely, supported in production, and improved using feedback. Reliable practices make work visible, limit the impact of mistakes, and help teams learn without assigning blame.

Integrating changes safely

Integration combines changes from multiple contributors into a shared codebase and checks whether the result works as a whole. Frequent integration can reveal conflicts and defects while changes are still small. Teams commonly use version control and a continuous integration (CI) pipeline that builds the software and runs automated checks whenever a change is submitted.

A pull request coordinates review, discussion, and automated testing before a change is merged. Repository rules can require an approving review or successful status checks before changes enter a protected branch.

For example, a developer changing a payment service might open a small pull request. The CI pipeline builds the service and runs unit and integration tests. If a test fails, the team investigates before merging, when the cause is easier to isolate.

Releasing and recovering

A release makes a particular software version available to users or operators. A sound release process supports consistent deployment and helps teams detect or limit harm if a change behaves unexpectedly.

Common practices include:

• Build once and promote the same artifact: Use the tested build in each environment, supplying environment-specific configuration separately.

• Automate repeatable steps: Automate deployment and basic post-deployment checks where practical, and keep deployment scripts and configuration under version control.

• Release in manageable increments: Small changes are generally easier to test, understand, and recover from than large bundles of changes.

• Monitor and prepare recovery: Check service health after deployment and have a tested way to roll back or otherwise mitigate a bad release. For higher-risk changes, a staged rollout, such as a canary to a small share of users, can reveal problems before wider exposure.

Continuous delivery aims to keep changes releasable on demand. Deployment automation helps make releases repeatable and lower-risk.

Coordinating project work

Project coordination helps people understand the goal, work, responsibilities, dependencies, and current status. Teams can coordinate through a prioritized backlog, clear ownership, short planning and review cycles, and shared records of important decisions. A useful work item states the intended outcome and how the team will recognize completion. Dependencies between teams or components should be surfaced early because they can affect sequencing and delivery dates.

Coordination involves more than status reporting. Regular communication with stakeholders helps confirm priorities, surface blockers, and incorporate feedback. Agile principles emphasize frequent delivery of working software, collaboration between business stakeholders and developers, and adapting plans as circumstances change.

Managing project risks

A risk is an uncertain event or condition that could affect a project or its software. Risk management is an ongoing cycle:

1. Identify possible risks, such as unfamiliar technology, a critical supplier dependency, or an unclear requirement.

2. Assess likelihood and potential impact so the team can prioritize attention.

3. Plan a response: Reduce likelihood or impact, prepare a contingency, avoid the risk by changing the plan, or knowingly accept it.

4. Monitor and revise: Revisit risks as the project changes and record new ones.

A lightweight risk register can record each risk, its impact, an owner, a planned response, and a review date. For example, if a service depends on an external provider, the team might document the risk of provider downtime, add monitoring, and define a fallback procedure.

Maintaining software in use

Software maintenance begins when software is in use; it is not simply a final phase after development. Teams maintain software by fixing defects, adapting it to changed environments, updating dependencies, addressing vulnerabilities, and improving reliability and usability. Monitoring, support requests, and incident reports provide evidence about what needs attention.

Maintenance work should be planned alongside new features. Prioritization considers user impact, security, reliability, cost, and the consequences of delaying a change. Security practices should be integrated throughout the software development lifecycle, including processes for responding to vulnerabilities in released software.

Improving through evidence and feedback

Continuous improvement means regularly using evidence and feedback to make the product and the way of working more effective. Teams can review delivery data, user feedback, test failures, operational incidents, and recurring delays to identify opportunities for change.

Useful measures might include the time a change takes to reach users, deployment frequency, release failure rate, and recovery time. No single measure fully describes performance.

After an incident, a blameless review focuses on what happened, how systems and processes contributed, and what actionable changes could prevent or reduce similar harm. Actions should have clear owners and be tracked to completion. The team can then check whether the changes improved outcomes and adjust again.