forked from KTH/devops-course
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
53 changed files
with
1,748 additions
and
11 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,34 @@ | ||
| name: Lecture Participation Information | ||
|
|
||
| on: | ||
| issue_comment: | ||
| types: [created] | ||
|
|
||
| permissions: | ||
| issues: write | ||
|
|
||
| jobs: | ||
| track-participation: | ||
| if: github.event.issue.number == 2370 | ||
| runs-on: ubuntu-latest | ||
| steps: | ||
| - uses: actions/checkout@v4 | ||
|
|
||
| - name: Setup Python | ||
| uses: actions/[email protected] | ||
| with: | ||
| python-version: '3.11.8' | ||
|
|
||
| - name: Install dependencies | ||
| run: | | ||
| python -m pip install --upgrade pip | ||
| if [ -f ./tools/requirements.txt ]; then pip install -r ./tools/requirements.txt; fi | ||
| - name: Update participation tracker | ||
| working-directory: tools | ||
| env: | ||
| GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} | ||
| REPO_FULLNAME: ${{ github.repository }} | ||
| TRACKER_ISSUE_NUMBER: ${{ github.event.issue.number }} | ||
|
|
||
| run: python track_participation.py --printMarkdown --publish |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,27 @@ | ||
| # Assignment Proposal | ||
|
|
||
| ## Title | ||
|
|
||
| Automating Software Releases with jReleaser and GitHub Actions | ||
|
|
||
| ## Names and KTH ID | ||
|
|
||
| - Hugo Malmberg ([email protected]) | ||
| - Oscar Hellgren ([email protected]) | ||
|
|
||
| ## Deadline | ||
|
|
||
| - Week 3 | ||
|
|
||
| ## Category | ||
|
|
||
| - Demo | ||
|
|
||
| ## Description | ||
|
|
||
| We will demonstrate how to automate the software release process using jReleaser and GitHub Actions. The GitHub Actions workflow will be triggered when a new release tag is pushed to the repository. jReleaser will handle tasks such as generating a changelog from commit messages, packaging the software, signing artifacts. | ||
|
|
||
|
|
||
| **Relevance** | ||
|
|
||
| jReleaser is an emerging tool for automating software releases, making it a valuable addition to any DevOps pipeline. This demo will show how jReleaser can simplify the release process by automating tedious tasks like changelog generation, artifact signing, and multi-platform distribution. Using GitHub Actions for automation further showcases how continuous integration and delivery can be extended to cover the entire lifecycle of a software project, from code changes to final release. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,28 @@ | ||
| # Assignment Proposal | ||
|
|
||
| ## Title | ||
|
|
||
| Automated Changelog-Driven Deployments with GitHub Actions and Release Please | ||
|
|
||
|
|
||
| ## Names and KTH ID | ||
|
|
||
| - Johann Biörck ([email protected]) | ||
| - Max Israelsson ([email protected]) | ||
|
|
||
| ## Deadline | ||
|
|
||
| - Week 3 | ||
|
|
||
| ## Category | ||
|
|
||
| - Demo | ||
|
|
||
| ## Description | ||
| We want to demonstrate how to automate versioning and changelog generation into an automated CI/CD pipeline (GitHub Actions) using release-please, ensuring that new updates are correctly tracked and reflected in production deployments. To display changes clearly, we want to create a simple website which we will make small changes on during the demo. During the demonstration we plan to show a commit with a conventional commit message that release-please accepts and we also plan to show what happens when you write a commit message which is not accepted. | ||
|
|
||
|
|
||
| **Relevance** | ||
|
|
||
|
|
||
| An important part of DevOps and CD is automation, and this automates part of the CI/CD pipeline. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,30 @@ | ||
| # Assignment Proposal | ||
|
|
||
| ## Title | ||
|
|
||
| From Continuous Delivery to Continuous Deployment in GoCD with Gomatic. | ||
|
|
||
|
|
||
| ## Names and KTH ID | ||
|
|
||
| - Leo Vainio ([email protected]) | ||
| - Oscar Olsson ([email protected]) | ||
|
|
||
| ## Deadline | ||
|
|
||
| - Week 3 | ||
|
|
||
| ## Category | ||
|
|
||
| - Demo | ||
|
|
||
| ## Description | ||
|
|
||
| Story: Manager wants to go from Continuous Delivery to Continuous Deployment using the same platform (GoCD). | ||
|
|
||
| We will demonstrate how we can change the configuration in GoCD to go from Continuous Delivery to Continuous Deployment. We will use a small example project for this demo and we will use Gomatic to allow us to configure the GoCD pipeline in code. | ||
|
|
||
|
|
||
| **Relevance** | ||
|
|
||
| GoCD is a CI/CD tool which is useful to know how to use. Also, it’s important to understand the difference between Continuous Delivery and Continuous Deployment and in this demo our goal is to illustrate the main differences. In Continuous Delivery, changes that pass automated tests still need manual approval but in Continuous Deployment even the deployment step is automated. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,32 @@ | ||
| # Assignment Proposal | ||
|
|
||
| ## Title | ||
|
|
||
| An Interactive Demonstration of Automated Canary Deployment using AWS and GitHub Actions | ||
|
|
||
| ## Names and KTH ID | ||
|
|
||
| - Noak Jönsson ([email protected]) | ||
| - Marcus Alström ([email protected]) | ||
|
|
||
| ## Deadline | ||
|
|
||
| - Week 3 | ||
|
|
||
| ## Category | ||
|
|
||
| - Demo | ||
|
|
||
| ## Description | ||
| A live demonstration of how GitHub actions and AWS can be used to achieve Automated Canary Deployments. | ||
| We will start off by inviting the audience to visit an application we have deployed using ECS on AWS. | ||
| We will then show how newly commited code on github can be automatically deployed to our ECS which will be accesible by a specified percentage of users through the use of a load balancer. | ||
| After explaining our use of the Canary deployment strategy, and how this can be achieved in AWS, we will then ask the audience to again view the application, where some will see the newest deployed version (... and some might even see a bug), while the rest will see the stable version. | ||
| Lastly we will show how to rollback a deployed verion in case of a bug being reported. | ||
|
|
||
| **Relevance** | ||
|
|
||
| Canary Deployment, or any form of Progressive deployment, is an effective Continuous Deployment technique which allows new code changes to be deployed to a subset of users, rather than the entire user base, ensuring that any bugs which were not discovered during testing are not deployed to all users. | ||
| Continuous deployment allows for a more rapid feedback loop with users, leading to unwanted features or bad design choices being reported back to developers faster who can then make adaptations in their strategy. | ||
| However, as software bugs are inevitable, and no testing framework is guaranteed to discover all bugs or erroneous behavior, canary deployment adds an extra safety net where critical bugs are not deployed to an entire user base. | ||
| AWS is a leading provider of cloud services and thus seems like a good candidate for showing a practical example of this type of deployment. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,34 @@ | ||
|
|
||
| # Assignment Proposal | ||
|
|
||
| ## Title | ||
|
|
||
| Reducing Downtime with Blue-Green Deployment using Vercel | ||
|
|
||
| ## Names and KTH ID | ||
|
|
||
| - Noel Tesfalidet ([email protected]) | ||
| - Milad Farahani ([email protected]) | ||
|
|
||
| ## Deadline | ||
| - Week 3 | ||
|
|
||
| ## Category | ||
| - Demo | ||
|
|
||
| ## Description | ||
| This demo will cover the importance of having a deployment strategy and show how | ||
| blue green deployment can be achieved on the web hosting platform Vercel (https://vercel.com/). | ||
| The demo will entail showing some basic website (Blue environment) and making a small change | ||
| to the site (Green environment) during the demo. The new deployment/website will be configured on stage to direct some of | ||
| the traffic to the domain to go to the Blue environment and some to the Green environment with no downtime. | ||
|
|
||
| **Relevance** | ||
| Blue-Green Deployment is relevant to DevOps because it provides a strategy for seamless | ||
| releases with minimal downtime. This is a core objective of DevOps practices. When having | ||
| two separate environments, a "Blue" one for the current version and a "Green" one for the | ||
| new version, it allows teams to deploy new code with safety. Developers can also test the | ||
| code in production and switch traffic between environments with minimal risk. This strategy | ||
| reduces the impact of failures and enables quick rollbacks. It also promotes continuous | ||
| delivery and deployment, which improves factors such as speed and reliability of software releases. | ||
|
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,26 @@ | ||
| # Assignment Proposal | ||
|
|
||
| ## Title | ||
|
|
||
| Gitlab CI/CD workflow for deploying fullstack web application on self-hosted server via docker. | ||
|
|
||
| ## Names and KTH ID | ||
|
|
||
| - Rikard Johansson ([email protected]) | ||
| - Mille Af Rolén ([email protected]) | ||
|
|
||
| ## Deadline | ||
|
|
||
| - Week 3 | ||
|
|
||
| ## Category | ||
|
|
||
| - Demo | ||
|
|
||
| ## Description | ||
|
|
||
| In this demo, we will walk you through configuring GitLab CI/CD for the automated deployment of a full-stack web application on a self-hosted server using Docker. We will cover the prerequisites, CI/CD variables, setting up a Docker image, installing necessary packages, SSH access to the server, and pulling the latest Docker container to recreate the application. | ||
|
|
||
| **Relevance** | ||
|
|
||
| This demo is relevant because it demonstrates how to streamline the deployment process using GitLab CI/CD, on a self hosted server. Automating the deployment of a full-stack web application reduces manual effort. By integrating Docker, it enhances portability and scalability, allowing developers to deploy applications seamlessly to self-hosted servers or other environments. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,30 @@ | ||
| # Assignment Proposal | ||
|
|
||
| ## Title | ||
|
|
||
| Deployment and rollbacks with Kubernetes | ||
|
|
||
| ## Names and KTH ID | ||
|
|
||
| - Robin Claesson ([email protected]) | ||
| - Simon Hocker ([email protected]) | ||
|
|
||
| ## Deadline | ||
|
|
||
| - Week 3 | ||
|
|
||
| ## Category | ||
|
|
||
| - Demo | ||
|
|
||
| ## Description | ||
|
|
||
| We want to give a demo for how you can configure a Kubernetes cluster. We will start with giving a short introduction into the world of microservice and container architecture, then dive straight into Kubernetes and its purposes. | ||
|
|
||
| We will then begin the demo by showing a configuration file for a Kubernetes cluster, and then start it up, showing how the cluster represents the configuration. Following that, we demonstrate how to increase the replicas of a pod to scale with demand. | ||
|
|
||
| We will then update the configuration to change the version of one of the pods and show how the cluster is updated. This new version will contain a bug, and to fix this we will show how to use the rollback feature of Kubernetes to go back to the previous working version, then deploy a corrected version without the bug. | ||
|
|
||
| **Relevance** | ||
|
|
||
| Kubernetes a modern system for deploying containers in a micro service architecture. As applications grew to hold many complex containers across numerous servers, the system would become too complex for mainstream services to keep up. Problems arose consisting of how to coordinate, schedule and communicate between such an abundance of containers, how to scale them, etc. Google introduced Kubernetes to solve these problems. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,35 @@ | ||
| # Assignment Proposal | ||
|
|
||
| ## Title | ||
|
|
||
| Continous Deployment and Rollback using Railway | ||
|
|
||
| ## Names and KTH ID | ||
|
|
||
| - Sam Khosravi ([email protected]) | ||
| - Atheer Salim ([email protected]) | ||
|
|
||
| ## Deadline | ||
|
|
||
| - Week 3 | ||
|
|
||
| ## Category | ||
|
|
||
| - Demo | ||
|
|
||
| ## Description | ||
|
|
||
| Our demo will show how one can deploy their github project using Railway, we will show how to set up the connection with Railway so that the project becomes deployed. | ||
| Then we will show how the application redeploys when the code changes (continuous deployment). | ||
| Finally we will show one can perform a rollback to previous deployment using Railway. | ||
| Along the way we will also showcase relevant features that Railway provides that are tied with the demo like showing build logs, and deployment logs, | ||
| where one can set environment variables, and monitor resource usage (here, we will only show the CPU and memory usage of the deployment). | ||
|
|
||
| **Relevance** | ||
|
|
||
| The proposal is relevant to DevOps as it shows how Railway can be used as tool to perform Continuous Deployment (CD) which is a big part of DevOps. | ||
| Also we are showing rollbacks which is also an important feature to have when using Continous Deployment, and finally we are introducing Railway to everyone in the | ||
| class (Railway has never been showcased before) which can be used to deploy various other things like databases and docker images. | ||
|
|
||
|
|
||
|
|
Oops, something went wrong.