Midterm Exam - Ansible to Docker DevOps
Some projects in Pusilkom UI have automated provisioning and deployment implemented using Ansible. The application and environment configuration are parameterised using Ansible variables that written in Jinja syntax and stored in YAML files. Since some of the variables might contain sensitive information such as database password or API key, Ansible Vault is also used to separate sensitive variables to a new file and encrypt it for storage in the version control system (Git). The variables will only be decrypted during provisioning and deployment process.
In recent times, there are requests to prepare a Docker-based deployment using
Docker Compose. One way to configure an application or a component running in
a container is by providing the configuration through environment variables.
To make it easier for DevOps Engineer or System Administrator to provide the
environment variables, usually they write the variables into a text-based file
called .env
that subsequently will be read by Docker Compose.
The problem is how to keep existing Ansible-related artefact in place and make
them still usable for Docker-based deployment. Since most of the configuration
are written in YAML files, there must be a way to reuse the configuration
variables in YAML files and transform them into a .env
file. In addition,
the values for some of the variables might also get passed through environment
variables when run in CI environment.
The following example is a program that reads YAML files, merge them into single
structure, and print the content as string that can be written into a .env
file:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 |
|
Actual, but redacted running example:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
|
The example above reads two YAML files named vars.yml
and vault.yml
.
The program replaces all occurences of Jinja variables in the vars.yml
with
values read from vault.yml
. In addition, if there are still some Jinja
variables left in the vars.yml
, the program reads the OS' environment
variables to obtain the values for the remaining Jinja variables. Finally,
any remaining Jinja variables will be assigned with empty values then
printed to the standard output.
SQA Problem - Input Space Partitioning
Estimated time: 5 minutes
You are asked to design an input space model for the API by following a functionality-based approach. The information required to develop the model can be derived by reading the code snippet.
Your tasks are as follows:
-
Determine the characteristics and the partition for a function chosen by the proctor.
Possible functions:
is_valid_yaml_files()
main()
- The whole script, i.e.
create_dotenv.py
-
Based on the input space model that you have created, create the test requirement and the test cases based on certain coverage criteria chosen by the proctor.
Possible coverage criteria choices:
- All Combinations Coverage (ACoC)
- Each Choice Coverage (ECC)
- Pair-Wise Coverage (PWC)
- Base Choice Coverage (BCC)
Note: You do not have to write all test cases due to the time limit. However, make sure you can justify your subset of test cases match with the chosen coverage criteria!
Write your answer in a sheet of paper or Microsoft Word/Google Docs document. You may include illustrations in your answer. Please prepare to present your answer remotely via Zoom/Google Hangouts during discussion time.
SQA Problem - Graph Coverage
Estimated time: 5 minutes
You are asked to design a control flow graph (CFG), prepare the test requirement, and create the test paths.
Your tasks are as follows:
-
Create the CFG for a function chosen by the proctor.
Possible functions:
is_valid_yaml_files()
main()
- The whole script, i.e.
create_dotenv.py
-
Based on the CFG that you have created, create the test requirement and the test paths based on certain coverage criteria chosen by the proctor.
Possible coverage criteria choices:
- Node Coverage (NC)
- Edge Coverage (EC)
- Edge-Pair Coverage (EPC)
Note: You do not have to write all test paths due to the time limit. However, make sure you can justify your subset of test paths match with the chosen coverage criteria!
Write your answer in a sheet of paper or Microsoft Word/Google Docs document. You may include illustrations in your answer. Please prepare to present your answer remotely via Zoom/Google Hangouts during discussion time.
SQA Problem - Discussion
Estimated time: 10 minutes
You are asked to present your answers to the given problems and also to have one-on-one interview with the proctor during the discussion time.
The list of topics that might be discussed is as follows:
- Code coverage (line coverage)
- Test-Driven Development (TDD)
- Test isolation
- Writing test cases in Java (JUnit)/Python (
unittest
and Django)/PHP (PHPUnit) - Your experience in conducting SQA activities in academics and/or work environment
- The ideas of mutation testing
- And many more that may still related to SQA
Created: 2021-11-10 11:48:10