The days of manually deploying enterprise applications have long passed. Today, automation and continuous integration/continuous delivery (CI/CD) are essential parts of the modern software development lifecycle (SDLC). As a result, more companies want enterprise architects to incorporate CI/CD tools and processes into their architectural designs.
Early on, CI/CD was a distinct practice in the SDLC process. Deployment engineers had dedicated tools for deployment. However, as the practice matured, CI/CD spread into other areas of the SDLC, with the most telling example being GitOps. Under GitOps, the source code repository becomes the single source of truth for CI/CD activity. The deployment server becomes the agent that expresses that truth. It's a fundamentally different approach to deploying enterprise applications.
My article A developer's guide to CI/CD and GitOps with Jenkins pipelines provides a detailed look at implementing a GitOps approach to automated application deployment by using a Jenkinsfile in a GitHub repository to drive a CI/CD deployment using the very popular CI/CD tool Jenkins.
A Jenkinsfile is a script that tells Jenkins exactly how to conduct a CI/CD process. Jenkins looks to the Jenkinsfile to learn how to do its work. The source control repo (in this case, GitHub) controls that Jenkinsfile. Should architects want to make a change in a deployment process, the only thing they need to change is the Jenkinsfile. Other than an initial, one-time setup, you don't need to do any twiddling with the Jenkins server directly. Taking a GitOps approach to deployment is a compelling approach to application provisioning architecture.
You can learn more about using Jenkins pipelines in your enterprise architecture design in A developer's guide to CI/CD and GitOps with Jenkins pipelines.