Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: continuous deployment #2019

Closed
wants to merge 8 commits into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
41 changes: 41 additions & 0 deletions docs/docs/20-usage/33-continuous-deployment.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,41 @@
# Continuous Deployment
Copy link
Member

@anbraten anbraten Jul 21, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general this is a nice overview, but I think its to generic to be actually helpful. I think we should rather add a new category: cookbook #316 or articles to our new blog with concrete tutorial styled guides. So something like to deploy a docker container with ansible you would first build the container with WP, add it to a registry and then run an ansible script to deploy the new container with woodpecker configs included.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When you create the cookbook page I can convert this to that format. Just tell me what you want me to do?


A typical CI pipeline contains steps such as: _clone_, _build_, _test_, _package_ and _push_. The final build product may be binaries 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 an 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://plugins.drone.io/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)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure what this has to do with WP and why we should recommend it?

Copy link
Contributor Author

@lonix1 lonix1 Jul 22, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is one option for doing CD. The same can be done with drone. The last step invokes ansible to do the deployment. Personally I'm using ansible but I think it;s overkill unless you are deploying to more than one server. For multiple servers (and if you are not using k8s) then it's a good option.


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.