Right now all workflows are run in parallel, meaning that some could fail while CD succeeds. Could possibly lead to live server crash?

Think about, discuss in your groups, and note down in which way you are going to collaborate using Git in this project.

You should reflect and decide on the following points:

• Which repository setup will we use?
• Which branching model will we use?
• Which distributed development workflow will we use?
• How do we expect contributions to look like?
• Who is responsible for integrating/reviewing contributions?

Information to at least all of the above points should end up in a markdown document in your main repository (likely called CONTRIBUTE.md).

We recommend that you do not rewrite history by rebasing or squashing your commits. The main reason is that it remains visible in the history who did what and when.

When you access the endpoint of a nonexistent user, you still get to see the private page of that user. Instead, this should give a 404 or another error message.

Tracking issue for:

• https://github.com/simonskodt/itu-minitwit/security/code-scanning/104

Our curret solution takes fetches all message on /public, foeach message, the userID is used to calls the backend for the username. The implementatio nis not optimal, and triggers alooot of traffic.

GroupJ -[checks]> GroupK

(A little late, we're sorry 😅)

Functionality Checks

• Do you see a public timeline?
• Does the public timeline show messages that the application received from the simulator?
• Can you create a new user? (Greetings from niceness1)
• Can you login as a new user?
• Can you write a message?
• After publishing a message, does it appear on your private timeline? (1)
• Can you follow another user? (2)

Additional notes:

1. It works very nicely! I can even send emojies :) It does however require me to either reload the page to my twit to appear.
   • Additionally, nothing told me the Twit had been posted so I accidentally Twitted(posted) the same thing twice. What are all my followers gonna think of me? 😭
2. I was unable to find a follow button, sadly. So my private timeline will have to be all about me! 😈
3. Visiting the timeline of another user correctly displays their messages. However, any name that contains spaces now has "%20" instead of a space and their Avatar-icon has been changed.
   • As seen on the public timeline:
     
   • As seen on the timeline of a particular user
     
4. Also, there is an evil "&apo;" in the "what's on your mind"-form-label-thingy (for adding Twits).
   • Here's a picture for good measure.
     

In the headers of some of the sim requests, the authorization header is not present.

• Deploy the current release of your ITU-MiniTwit, see task 2 b), to a remote ("cloud") server.

  • You might want to deploy to DigitalOcean, from where you get free credits from the GitHub education pack.
  • You might want to start with the exercise from the demo in the lecture, see slide g) Automatic provision of remote clusters of virtual machines at DigitalOcean via Vagrant.
  • OBS: The simulator API from the task above is considered part of your ITU-MiniTwit, i.e., it has to be deployed too.

• Do not create and provision VMs manually, instead use a corresponding script, Vagrantfile, or a similar reproducible setup for that task.

• You are free to deploy to whichever Infrastructure-as-a-Service (IaaS) provider of your choice or your own servers.
  The only requirement is that your deployment is automatically reproducible, i.e., no clicking in UIs required, and that your application is reachable via a public IP/domain.
  Do not deploy to a Platform-as-a-Service, like Heroku, Google App-Engine, etc.

• Make your development environment and deployment environment "look alike". That is, you develop on an Ubuntu 22.04 based Linux (Pop!_OS), choose the same environment for your remote server(s).

• Hint: To make future operations more smooth, you might consider to use a floating IP 'infront' of your actual server, see the API spec. for receiving one.

Add layers relevant to onion architecture.

In the format:

/msgs?n=10

• The test suite in minitwit_tests.py should pass for your refactored application too. Likely, you have to modify the setup method slightly so that it points to your application.

• However, all test methods of the API tests should pass on your refactored application.

• First in a next step translate the old test suite to your new language/tech. stack too.

• Rewrite the application in mini-steps at a time.

  • For example, a very first step could be: Given a database, I want to show the public timeline.
  • A second step could then be: I want to be able to see the public timeline of one user.
  • ...

• Prepare a new release with the refactored version of your ITU-MiniTwit latest by Sunday Feb 19th, at 22:00)
• Send a pull request to repositories.py in our central repository: https://github.com/itu-devops/lecture_notes/blob/master/repositories.py
  • Add two URLs:
    • One to your running applications (edit "http://<minitwit_application_url>")
    • Another one to the simulator API endpoint (edit "http://<sim_api_url>")

Error message: System.FormatException: Element 'latestVal' does not match any field or property of class MiniTwit.Core.Entities.Latest.

Something in the flow of the service layer regarding the latestVal

For your refactoring work, use Docker. That is create respective Dockerfiles and Docker Compose files in your repository. These containerize your application and allow all team members to develop your application in a uniform environment.

Split single repositories into 3
Let repositories return response and remove service layer project

You can find the specification for the simulator API in API_Spec/minitwit_sim_api.py. OBS: your applications have to:

• provide the same end points (on different hosts of course and potentially different ports),
• ingest the same HTTP requests, i.e., GETs and POSTs as specified with the same parameters and payloads as provided,
• provide at least the same HTTP status codes in response as specified.

The API_Spec/minitwit_sim_api.py depends on your refactored minitwit.py from last week's homework.

A corresponding test (API_Spec/minitwit_sim_api_test.py) illustrates how the simulator requests will be formed. You can inspect it and run it via pytest minitwit_sim_api_test.py. (pytest can be installed via pip)

Next to the unit test, there is a small program with some more test data, which is similar to the simulator program that will run against your systems. It is located in API_Spec/minitwit_simulator.py and can be run via:

$ python minitwit_simulator.py http://localhost:5001

where the argument http://localhost:5001 has to be replaced with the URL of where your simulator API is running. In case this simulator test does not log any errors, you should be all fine for next week. If errors are logged, you have to fix the corresponding issue either in your implementation of the simulator API or in the implementation of your version of ITU-MiniTwit.