Continuous Delivery and Release Engineering
Continuous Delivery: Reducing the cost, time, and risk of delivering incremental changes to users.
Continuous Delivery develops a team's capability to have the code in an always deployable state. It mandates engineers to merge their code daily, never breaking the mainline, and delivering features incrementally. This is typically done by developing pipelines that build, test, and deploy the code in production.
It draws inspiration from Lean Manufacturing that urges investment in machinery to cut costs over time. Soon enough, the team establishes discipline and improves the delivery process iteratively that deploying the product becomes boring.
This is not possible (at least, not as fast) when there are tens of teams contributing to a product. This can be a matter of scale or the nature of the software but often both are true. The breed of software RelEng practices apply to is inherently different from applications that are able to establish the practice of Continuous Delivery. Operating systems and downloadable software often fall under the former while web applications or Indie developed apps in the latter.
Continuous delivery is micro-focused whereas Release engineering is macro. Continuous delivery promotes practices engineers follow to allow their team's work be shipped readily. This falls short when the build processes of a complex product takes hours or days and requires multiple components to form a monolithic binary.
For bigger companies, continuous delivery may come into play in the form of a mono-repository pattern. Each team works on a part of the software that gets deployed periodically or at-will. Because Release Engineering typically results in a downloadable binary which requires compilation and other build operations, a similar approach is not generally appropriate for Continuous Delivery.
The scale of continuous delivery is arguably different. Typically, smaller teams with a streamlined process implement continuous delivery processes easily. You can potentially create a whole CD pipeline using just GitHub Actions, for example. What's not easy might be the discipline the software developers need to develop to reap the full benefits of continuous delivery.
While these two methodologies are employed for different scale and needs, both emphasize reducing the cost, time and risk to delivering changes to customers. The idea is to let the machines take on repeatable tasks and script the toil away.
When there are tens of teams contributing to a large product separately, Release Engineering establishes the practices and paradigms so teams can focus on writing code within their area of expertise, get meaningful feedback reliably, and let releasing software be a separate worry.