Commit b295b4818300af870e444d61bcbbfdc4b782f40f
Merge branch 'documentation' into documentation
# Conflicts: # docu/project_documentation.md
Showing
2 changed files
with
74 additions
and
19 deletions
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._ | ... | ... |