---

1.1 Welcome

• this course is for people new to DevOps who want to use GitLab to build, test and deploy their software
• you will get hands-on experience building pipelines with GitLab CI and deploying software to AWS

---

2.1 Unit overview

• we will start working on a simple website project
• we want to automate any of the manual steps required for integrating the changes of multiple developers
• we will create a pipeline that will build and test the software we are creating

---

3.1 Unit overview

• we will learn about deployments and take our website project and deploy it to the AWS cloud.
• learn about other DevOps practices such as CI/CD

---

3.2 A quick introduction to AWS

• AWS (Amazon Web Services) is a cloud platform provider offering over 200 products & services available in data centers all over the world
• you need an AWS account to continue with the rest of the course

---

4.1 Section overview

• modern applications tend to be more complex, and most of them use Docker
• we will build & deploy an application that runs in a Docker container

---

4.2 Introduction to AWS Elastic Beanstalk

• AWS Elastic Beanstalk (AWS EB) is a service that allows us to deploy an application in the AWS cloud without having to worry about managing the virtual server(s) that runs it

---

Lesson 1 - Final assignment

• request access as a member to the project
• add your name to the list of people who have completed this course

📚 Resources

• Join the project
• How to fix merge request conflicts

---

• Unit 1 - Introduction to GitLab
• Unit 2 - Continuous Integration with GitLab CI
• Unit 3 - Continuous Deployment with GitLab & AWS
• Unit 4 - Deploying a dockerized application to AWS
• Unit 5 - Conclusion

---

Project Setup

Once you have checked off the list of prerequisites, it's time to create a new Quarkus project. There are multiple ways to do this, but for simplicity, I will use the Quarkus project configurator. This tool empowers you to quickly assemble a complete build file with the necessary dependencies.

---

It is now time to look at the application architecture. The objective is to establish endpoints that serve film-related information to clients. For the sake of clarity and separation of concerns, I've chosen to adopt a straightforward Repository Pattern.

Below is a snapshot of how the architectural pieces will fit together when you are done. The Resources class takes on the responsibility of delivering database-derived content to clients. However, this class refrains from conducting the actual database interactions; instead, this task is entrusted to the Repository. This architectural approach neatly segregates the data layer from the other facets of our application.

---

Fetching Films with Java Streams and JPAStreamer

So far our application has not touched the database, but that is our next move. We start simple and gradually build up Stream queries that are more powerful.

Initiate this process by establishing a dedicated repository package adjacent to the existing model package. Inside this repository section, create a class named FilmRepository. As the name implies, this class will serve as the hub for our database queries. This class needs to be annotated with @ApplicationScoped for it to be injected into your FilmResource later.

---

Continuous Testing

You can configure Quarkus to automatically trigger the execution of your JUnit test suite every time you run your application. Or alternatively, trigger the execution manually by pressing [r] in the Quarkus dev terminal. Before, I understood the value of test-driven-development (TDD) but I have always felt it got in the way of focusing on the business logic as I would only run them occasionally. This does not mean Quarkus writes the tests for you, but they are easy to execute and the dev mode constantly reminds you that they are there.