aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorDiederick de Vries <diederick76@users.noreply.github.com>2017-05-05 23:06:01 +0200
committerGitHub <noreply@github.com>2017-05-05 23:06:01 +0200
commit7ea66e386aeb9b152bdee84f8ef3f06f1fb05b4c (patch)
treebdf7b5fdf8e2adb868d681db39ad53a9c6982687
parentb6d9151a85fb87662316fa640224f8b88cd0e581 (diff)
downloadaside-7ea66e386aeb9b152bdee84f8ef3f06f1fb05b4c.tar.gz
aside-7ea66e386aeb9b152bdee84f8ef3f06f1fb05b4c.tar.bz2
aside-7ea66e386aeb9b152bdee84f8ef3f06f1fb05b4c.zip
Updated README.md
-rw-r--r--README.md48
1 files changed, 26 insertions, 22 deletions
diff --git a/README.md b/README.md
index 456ea30..d7630db 100644
--- a/README.md
+++ b/README.md
@@ -1,36 +1,36 @@
1# Introduction 1# Introduction
2 2
3ASiDe (A Simple Deployment pipeline) is a Continuous Integration and Deployment Pipeline. Is is meant to quickly, reliably and transparantly roll out updates with fixes and new features of projects. ASiDe aims to be technology agnostic and only depends on git, inotify and bash, and optionally on a mail server. 3ASiDe (A Simple Deployment pipeline) is a Continuous Integration and Deployment Pipeline. It is meant to quickly, reliably and transparantly roll out updates with fixes and new features of projects. ASiDe aims to be technology agnostic and only depends on git, inotify and bash, and optionally on a mail server.
4 4
5When the applied build script contains the needed test, build and deployment steps, all that is needed is a push to a master branch to release the new version of a project. Logs can be followed or emailed to the user afterwards. 5When the applied build script contains the needed test, build and deployment steps, all that is needed is a push to a master branch to release the new version of your project. Logs can be followed or emailed to the user afterwards.
6 6
7ASiDe consists of the following parts: 7ASiDe consists of the following parts:
8 8
9* A systemd-unit for turning the build trigger on or off: `/etc/systemd/system/asidtrigger.service` 9* A systemd-unit for turning the build trigger on or off: `/etc/systemd/system/aside.service`
10* A monitoring script using inotify to monitor which triggers appear in `/home/builduser/trigger/`: `/home/builduser/bin/monitor` 10* A monitoring script using `inotify(7)` to monitor which triggers appear in `/home/builduser/trigger/`: `/home/builduser/bin/monitor`
11* A post-update hook in each git repository: `/srv/git/&lt;projectname.git&gt;/hooks/post-update` 11* A post-update hook in each git repository: `/srv/git/&lt;projectname.git&gt;/hooks/post-update`
12* Build scripts which are triggered by the monitor script: `/var/home/builduser/&lt;projectname&gt;/bin/build` 12* Build scripts which are triggered by the monitor script: `/var/home/builduser/&lt;projectname&gt;/bin/build`
13 13
14# Flow 14# Flow
15 15
16Deploying is done by a dedicated user `builduser`. `/var/home/builduser/` looks as follows: 16Deploying is done by a dedicated user `builduser`. Its home `/var/home/builduser/` looks as follows:
17 17
18``` 18```
19 /var/home/ 19 /var/home/
20 builduser/ 20 builduser/
21 bin/monitor 21 bin/monitor
22 trigger/ 22 trigger/
23 <repo> 23 <projectname>
24 <repo>/ 24 <projectname>/
25 bin/build 25 bin/build
26 resources/ 26 resources/
27 test/ 27 test/
28 work/ 28 work/
29``` 29```
30 30
31The monitoring script uses the name of the trigger to select the correct project. Each project has a dedicated build script and resources used for testing when necessary. This way the development environment doesn't need to have those and they don't need to be committed to git, which would be insecure. 31The monitoring script uses the name of the trigger to select the correct project. Each project has a dedicated build script and resources used for testing when necessary. This way the development environment doesn't need to have those and they don't need to be committed to git, which could be insecure.
32 32
33When the systemd-unit is enabled, is is started by booting the build server. Then the flow is as follows: 33When the systemd-unit is enabled, it is started by booting the build server. Then the flow is as follows:
34 34
351. A developer pushes a change to `origin/master`. 351. A developer pushes a change to `origin/master`.
362. The post-update hook checkt that the branch is `master`. 362. The post-update hook checkt that the branch is `master`.
@@ -39,15 +39,15 @@ When the systemd-unit is enabled, is is started by booting the build server. The
395. The monitoring script notices the trigger and starts the build script in the repository with the name of the trigger. 395. The monitoring script notices the trigger and starts the build script in the repository with the name of the trigger.
406. Afterwards is emails the build script's output to the developer. 406. Afterwards is emails the build script's output to the developer.
41 41
42The example build script deploys a Java maven project. It runs the unit tests and copies the test resources to the project to run the integration tests. It then packages the project and copies the artifcact to an installation directory, to which builduser has writing rights. At last, it emails the logs to the developer and empties the working directory. 42The example build script deploys a Java Maven project. It runs the unit tests and copies the test resources to the project to run the integration tests. It then packages the project and copies the artifcact to an installation directory, to which builduser must have write rights. At last, it emails the logs to the developer and empties the working directory.
43 43
44# Starting and stopping 44# Starting and stopping
45 45
46Start, stop, enable and disable as you would any systemd unit. The unit is called `asidetrigger`. 46Start, stop, enable and disable as you would any systemd unit. The unit is called `aside`.
47 47
48# Installation 48# Installation
49 49
501. Create a system user `builduser` and a system group `deploy` with home directory `/var/home/builduser`. 501. Create a system user `builduser` and a system group `deploy` with home directory `/var/home/builduser`. Use a free group number under 1000, to indicate it is a system group. The example uses 900.
51 51
52``` 52```
53# groupadd -r -g 900 deploy` 53# groupadd -r -g 900 deploy`
@@ -57,9 +57,13 @@ Start, stop, enable and disable as you would any systemd unit. The unit is calle
572. Create a directory structure under `/var/home/builduser`. 572. Create a directory structure under `/var/home/builduser`.
58 58
59``` 59```
60# mkdir -p /var/home/builduser/{bin,trigger,repo1/{bin,log,resources/{test,prod},work}} 60# mkdir -p /var/home/builduser/{bin,trigger,project1/{bin,log,resources/{test,prod},work}}
61``` 61```
62 62
633. Put the scripts at the right location. See the diagram above. 633. Put the scripts at the right location and adapt them to your needs. See the diagram above.
64 64
654. Adapt all scripts to your setup. 654. Enable the triggers.
66
67```
68# systemd enable aside
69```