Commit b295b4818300af870e444d61bcbbfdc4b782f40f

Authored by Benjamin Rühl
2 parents a8a3ebca b67ee216

Merge branch 'documentation' into documentation

# Conflicts:
#	docu/project_documentation.md
README.md
... ... @@ -9,7 +9,8 @@ BeuthBot is a master project of the Beuth University of Applied Sciences Berlin.
9 9 - [Application properties](#application-properties)
10 10 - [Docker configuration](#docker-configuration)
11 11 - [Local tunnel](#local-tunnel)
12   -- [Debugging](#debugging)
  12 +- [Debug application](#debugging)
  13 +- [Deploy application](#aeploy-application)
13 14 - [Known issues](#known-issues)
14 15 - [Used online sources](#used-online-sources)
15 16  
... ... @@ -50,7 +51,7 @@ The project should be cloned from the repository. For development it is possible
50 51  
51 52 With the following command it is possible to build the whole project. The construction of the project is possible during operation and before starting the server. In the first case the running server is automatically updated during operation.
52 53  
53   -```
  54 +```bash
54 55 ./gradlew war
55 56 ```
56 57  
... ... @@ -58,17 +59,17 @@ With the following command it is possible to build the whole project. The constr
58 59  
59 60 The application can be started with the following command:
60 61  
61   -```
  62 +```bash
62 63 # Unix
63 64 ./gradlew chatbotRun
64 65 ```
65 66  
66   -```
  67 +```bash
67 68 # Windows
68 69 gradlew.bat chatbotRun
69 70 ```
70 71  
71   -```
  72 +```bash
72 73 # MacOS
73 74 cd docker
74 75 docker-compose up --build
... ... @@ -89,17 +90,17 @@ In addition it is also possible to set up your own bot for example, in Telegram
89 90  
90 91 The following command can be used to stop the running application:
91 92  
92   -```
  93 +```bash
93 94 # Unix
94 95 ./gradlew chatbotStop
95 96 ```
96 97  
97   -```
  98 +```bash
98 99 # Windows
99 100 gradlew.bat chatbotStop
100 101 ```
101 102  
102   -```
  103 +```bash
103 104 # MacOS
104 105 cd docker
105 106 docker-compose down
... ... @@ -176,30 +177,35 @@ MacOS:
176 177 MacOS requires XCode and Homebrew in order to install NodeJS.
177 178 XCode can be downloaded and installed for free via the App Store.
178 179  
179   -To install Homebrew, open a terminal window and type`
180   -```
  180 +To install Homebrew, open a terminal window and type
  181 +
  182 +```bash
181 183 ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
182 184 ```
183 185  
184 186 After Homebrew has completed installation, install NodeJS by typing:
185   -```
  187 +
  188 +```bash
186 189 brew install node
187 190 ```
188 191  
189 192 Finally install localtunnel by typing:
190   -```
  193 +
  194 +```bash
191 195 npm install -g localtunnel
192 196 ```
193 197  
194 198 If everything has worked correctly, you are now ready to use localtunnel.
195 199 Using localtunnel is fairly easy, simply type:
196   -```
  200 +
  201 +```bash
197 202 lt --port 8080
198 203 ```
199 204  
200 205 Where the number entered after --port corresponds to the port you want localtunnel to route its HTTPS-Domain to.
201 206 The localtunnel server can be slow and a little unreliable at times, but if everything goes well you should see something like:
202   -```
  207 +
  208 +```bash
203 209 your url is: https://uawfhausjdj.localtunnel.me
204 210 ```
205 211 which is the url you can put in the first line of the `beuthbot.properties` file in the /docker/wildfly/volumes/conf` directory.
... ... @@ -210,7 +216,7 @@ NOTE: Localtunnel tends to crash every now and then, displaying an error message
210 216  
211 217 <!-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -->
212 218  
213   -## Debugging
  219 +## Debug application
214 220  
215 221 At the moment, the JBoss server is always started with open debugging ports. To attach to the running docker container process using IntelliJ, a remote debug configuration has to be created. To do so, perform the following steps:
216 222  
... ... @@ -223,6 +229,59 @@ At the moment, the JBoss server is always started with open debugging ports. To
223 229  
224 230 <!-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -->
225 231  
  232 +## Deploy application
  233 +
  234 +The following paragraph describes how the deplyoment is performed from a local Git repository to the production server. All development statuses have to be transferred to the `master` branch before performing the deployment. Just from the `master` branch it is possible to carry out the deployment on the productive server. To be able to perform the deplyment, it is necessary to be able to access the server via SSH. Then Git will transfer the status of the `master` branch to the server. This requires customizations on the server and in the local Git.
  235 +
  236 +### 1. Setup on the server
  237 +
  238 +On the server the following Git command have to be executed in the directory `home/<user>/`. Instead of the placeholder `<projectname>` the actual name of the project has to be used. The command creates a Git directory which includes all necessary files for a Git Hook.
  239 +
  240 +```bash
  241 +git init --bare ~/<projectname>.git
  242 +```
  243 +
  244 +After the Git folder has been successfully created, a new file with the name `post-receive` has to be created in the subfolder `<projectname>.git/hooks`. Afterwards the script has to be inserted into this file and the placeholders get changed by project-specific variables. The script will also start the `deployment.sh` script. This executes the build of the project and starts the appropriate Docker command. In addition, this script ensures that the `beuthbot.properties` file on the server is replaced by the corresponding productive file. In local development the `post-receive` and `deployment.sh` file can be found in the `scripts/` folder.
  245 +
  246 +```bash
  247 +#!/bin/bash
  248 +while read oldrev newrev ref
  249 +do
  250 + # only checking out the master (or whatever branch you would like to deploy)
  251 + if [[ $ref =~ .*/master$ ]];
  252 + then
  253 + echo "Master ref received. Deploying master branch to production..."
  254 + git --work-tree=/home/<user>/<projectname>/ --git-dir=/home/<user>/<projectname>.git/ checkout -f
  255 + cd /home/<user>/<projectname>/
  256 + ./scripts/deployment.sh
  257 + else
  258 + echo "Ref $ref successfully received. Doing nothing: only the master branch may be deployed on this server."
  259 + fi
  260 +done
  261 +```
  262 +
  263 +In addition a folder with the project name `<projectname>` has to be created on the server in the directory `home/<user>/`. This is where the code from the `master` branch is pushed.
  264 +
  265 +```bash
  266 +mkdir ~/<projectname>
  267 +```
  268 +
  269 +### 2. Use in a local development environment
  270 +
  271 +This step sets up a reference to the server on which the application is deployed. For this the following command must be executed. The placeholder `<user>` has to be replaced by the matching SSH user and the project `<projectname>` that has been set up on the server.
  272 +
  273 +```bash
  274 +git remote add production ssh://<user>@<ip>:<port>/home/<user>/<projectname>
  275 +```
  276 +
  277 +After the Git remote settings have been made the current state of the `master` branch can be pushed to the server using the following command.
  278 +
  279 +```bash
  280 +git push production master
  281 +```
  282 +
  283 +<!-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -->
  284 +
226 285 ## Known issues
227 286  
228 287 The following issues are currently known in the application:
... ...
docu/infrastructure.md
... ... @@ -5,10 +5,6 @@ Each module is loosely connected through a Java Message Service. The application
5 5  
6 6 - see [docker compose file](../docker/docker-compose.yml)
7 7  
8   -The productive project is represented by a separate Git repository in absent of a continuous integration server.
9   -Pushing into the master branch of this repository should automatically trigger a rebuild of the productive environment.
10   -- confer [post-receive](../scripts/post-receive) - Git hook for auto deploying the application
11   -
12 8 ## Sub projects
13 9  
14 10 _**DISCLAIMER:** Please note that the following information is documented by the second project team who felt that a deeper look into the project structure should be a requirement for teams working on the project. This means that information is written 'as understood'. The original designers of the system had great knowledge of their architecture but sadly forgot to share it._
... ...