From 7786028b4a9aaff830d4606c438c66f3f8b184de Mon Sep 17 00:00:00 2001 From: qwerty287 <80460567+qwerty287@users.noreply.github.com> Date: Tue, 9 Jan 2024 19:47:25 +0100 Subject: [PATCH] Add continous deployment cookbook (#3098) 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> --- .../2024-1-1-continous-deployment/index.md | 52 +++++++++++++++++++ 1 file changed, 52 insertions(+) create mode 100644 docs/cookbook/2024-1-1-continous-deployment/index.md diff --git a/docs/cookbook/2024-1-1-continous-deployment/index.md b/docs/cookbook/2024-1-1-continous-deployment/index.md new file mode 100644 index 000000000..c1bedcc37 --- /dev/null +++ b/docs/cookbook/2024-1-1-continous-deployment/index.md @@ -0,0 +1,52 @@ +--- +title: Continuous Deployment +description: Deploy your artifacts to an app server +slug: continuous-deployment +authors: + - name: lonix1 + url: https://github.com/lonix1 + image_url: https://github.com/lonix1.png +hide_table_of_contents: 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](https://plugins.drone.io/plugins/ssh) or [git push](https://woodpecker-ci.org/plugins/Git%20Push). + +## 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](https://woodpecker-ci.org/plugins/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](https://github.com/adnanh/webhook) and [webhookd](https://github.com/ncarlier/webhookd). + +This is arguably the simplest and most maintainable solution.