7786028b4a
Supersedes https://github.com/woodpecker-ci/woodpecker/pull/2019 --------- Co-authored-by: lonix1 <40320097+lonix1@users.noreply.github.com> Co-authored-by: 6543 <6543@obermui.de> Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
2.7 KiB
| title | description | slug | authors | hide_table_of_contents | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Continuous Deployment | Deploy your artifacts to an app server | continuous-deployment |
|
false |
A typical CI pipeline contains steps such as: clone, build, test, package and push. The final build product may be artifacts pushed to a git repository or a docker container pushed to a container registry.
When these should be deployed on an app server, the pipeline should include a deploy step, which represents the "CD" in CI/CD - the automatic deployment of a pipeline's final product.
There are various ways to accomplish CD with Woodpecker, depending on your project's specific needs.
Invoking deploy script via SSH
The final step in your pipeline could SSH into the app server and run a deployment script.
One of the benefits would be that the deployment script's output could be included in the pipeline's log. However in general, this is a complicated option as it tightly couples the CI and app servers.
An SSH step could be written by using a plugin, like ssh or git push.
Polling for asset changes
This option completely decouples the CI and app servers, and there is no explicit deploy step in the pipeline.
On the app server, one should create a script or cron job that polls for asset changes (every minute, say). When a new version is detected, the script redeploys the app.
This option is easy to maintain, but the downside is a short delay (one minute) before new assets are detected.
Using a configuration management tool
If you are using a configuration management tool (e.g. Ansible, Chef, Puppet), then you could setup the last pipeline step to call that tool to perform the redeployment.
A plugin for Ansible exists and could be adapted accordingly.
This option is complex and only suitable in an environment in which you're already using configuration management.
Using webhooks (recommended)
If your forge (GitHub, GitLab, Gitea, etc.) supports webhooks, then you could create a separate listening app that receives a webhook when new assets are available and redeploys your app.
The listening "app" can be something as simple as a PHP script.
Alternatively, there are a number of popular webhook servers that simplify this process, so you only need to write your actual deployment script. For example, webhook and webhookd.
This is arguably the simplest and most maintainable solution.