 Παρακολουθούμε, και καλή afternoon to everyone. This talk is about our software journey through the development and deployment of a single web scale application using Zero-Course Infrastructure. My name is Nikon Doe, and I'm a backend engineer located in Athens, Greece. This is my partner in crime, George. Hello everyone, my name is George, I'm a UX engineer and a call contributor to GitLab. Nik will go through the task and the challenges and start the talk. So this slide is an overview of the whole presentation. We will use it as our own map for our thought process. Firstly, we will present the task and the backstory of the idea. Then we'll go through the challenges that we face along the way. In the third section, we will describe how we tackle the above challenges and present some useful metrics. Finally, we have some thoughts for future steps and what we have learned through the journey. Firstly, the task, how and why we start this project. Let's go a few months ago. Me and George went to grab a cup of coffee. At that period, George had something in his mind and a side project for a non-profit organization. To put some content, this organization helps homeless people with laundry services. The task was to help them, facilitate them with financial contributions. At that period, George was already familiar with DevOps, mainly with GitLab, and proposed to use this project as an opportunity to experiment with new development platforms, new development frameworks, and CI-CD best practices. Let's move on to the challenges. The first challenge that we faced was time, as I said before. This was a side project. The question was how to maximize the use of our free time. Firstly, we start by doing bi-weekly, slowly, by doing bi-weekly development sprints. Then, we start working asynchronously. It's more difficult for a side project to prioritize your time and put the appropriate commitment. Next, it's the size of a team. We are a team of two. This is a relatively small project. This may sound more flexible in terms of development, but it's actually efficient to adopt DevOps for small teams. At the beginning, it seems that it only adds extra overhead. At the same time, it is very tempting to ping the other team member directly, that this can be very efficient. Then, as a team, we all try to get better, better encoding, better documentation, learn about collaboration. How can we use this project for developing new skills? We choose to experiment with new frameworks, and that also puts extra overhead in the beginning. Then, it's all about the approach. We spend time adopting a new mindset. At that time, we didn't know if it was beneficial for a small project to invest time in DevOps. We haven't used much DevOps together, and this was our first time doing this together. About merge requests or reviews or the right Git flow, this is not to take for granted. It's all about the right mindset. For example, I tried to push in master lots of time, but thanks to George, it never happened. Finally, the biggest challenge was the cost. This is a non-profit organization, so the budget is very limited. For example, you have to load the cost even in the development mode. For example, it's a TPV request. To show the big picture, we refer about a dozen financial contributions per month, so it's a low-traffic project. How would we limit the infrastructure down to zero? We pick GitLab tier free-tire for source code management and CI. CI, meaning build, test, and deploy. Mongo Atlas DB for persisting the data, and Heroku for hosting the app, both the backend and the front-end as a single application. On the right, you see screenshots of the usage of GitLab and Heroku in the first month. The good thing with DevOps is that as we build our pipeline, it's very easy for us to go from the free-tire to the paid-tire if this is needed in the future. I'll pass to George to continue with CI-CD approach. Besides the source code management, we also had to pick up CI-CD approach, and this included practicing continuous degradation, and also choosing the right hosting provider. Let's go through this brief architecture, which we started splitting the applications to repositories, but that would require extra configuration and additional destruction for us. We decided to bundle the app in a single repository and using Express and Vue for faster development at the beginning. For front-end development, we wanted to try out Vue, especially after seeing Vue in action through GitLab, while contributing to GitLab. Regarding UX, we decided to pick up the existing template and layout of the parent website, so we actually used that. For back-end, we wanted to experiment with an old back-end, so we picked up Express. We wanted also to have efficient local development workflows that is using built tools and more. Our local environment also included docker containers for having local databases besides the third-party service. We also used the free-tire of GitLab and GitLab CI to actually build, test, and deploy the app. We also used the GitLab Flow to actually collaborate with MergeQuest and feature branching as a Git strategy for us. We started with having one pipeline at the beginning and one pipeline job and just started to build around this to experiment with building the front-end and the back-end application and testing and deploying it on separate environments which we'll talk about later on. Regarding CI-CD, we experimented with autodevops in the beginning. It was interesting. It's easy to actually get a full pipeline for apps and back-end and front-end without CI configuration, but we switched to manual configuration to fine-tune, let's say, and experiment with more CI practices. So let's go to deploying the app. In projects we've worked together with Niki, we used to have an event-based deployment mechanism based on Git hooks, so we wanted to try something else and something different. So having a Heroku deployment via the DPL tool on GitLab CI was much more efficient and effective and deploying automatically on production and also manually on staging due to tire limitations because optimally we could have multiple environments. We'll talk about this later too. Regarding the hosting, we experimented with other modern hosting providers like Zeit and Endlify, but we stick to Heroku due to the requirement, let's say, we had for a fixed IP for accessing the private banks' API during the process. And we also settled with Heroku for deploying and having a single review app per merge request when needed with manual deployment. So let's move into some developed metrics. We've used also GitLab to extract some of these. These are also available on gitlab.com. Let's go through development metrics where you can actually see some of the stats that I mentioned earlier. Some things that we didn't mention earlier was made in 30 active development days, so we worked together with Niki for 30 days to do this. Besides that, we opened 65 and 31 magic quests, some of them were closed, some of them weren't merged for the magic quest, and we actually used the two environments I mentioned earlier. Going through the average metrics per month, it's worth noting that the average time from mission creation until deploy, it's five days. This is stats that you can actually see in the GitLab interface for your projects. To the pipeline metrics, we actually had the pipeline that ran for 330 without the branch for deployment on the environment and 630 for including the deployment. This was before introducing, GitLab introduced the DAG, the DirectAquiclic graph support for pipelines, and actually Niki asked me about this just about a month ago before the introduction of that, and it was really fun to try this out and having gained 30 seconds of pipeline duration, just having a single pipeline with five jobs. Imagine what the impact of this would be in larger pipelines or structures where it's more complicated to run the pipeline. So, and now I'll pass to Niki to suffer some future steps, and Niki will go through the development part. So, these are the future steps for the development. So, want to add some new features. At the beginning, we only focus in providing single one-time donations. So, the goal is to also facilitate with recurring donations. Maybe we want to provide other services that you can do the donation through these services. And there are thoughts of supporting features like the ability to create a funding campaign. Then, testing. When we started, we didn't focus much on testing, and this means that in the future, when we will add some features, this can have side effects and the code may be unpredictable. So, there are issues for supporting testing, basic testing integration, unit test, end-to-end test. So, the ultimate goal is to support the more solid testing stage in the pipeline. And open source. So, when we started this project, we focused on a single non-profit, but in the process, we saw that this code may be beneficial for other non-profit organizations. So, there are thoughts to put it open source, but of course that means that we have to invest time in making the code more generic, more customized, so everyone can contribute, deploy and configure the code. And that also means that we have to spend time in creating good documentations and learn how you can maintain a community. So, George. So, we'll go through the operation side of the future steps we are thinking about. We decided to go with a single app in the beginning to actually make the development faster, but having these deployed separately on the front end and the back end could actually make the pipeline even more efficient and faster. So, splitting the apps, the front end and the back end apps could potentially make more efficient the time to deploy. We are also thinking of hosting the back end and the front end in the application delivery network for faster access. This will decrease... This will have great impact to the end user. And remember, the pipeline was also critical for us. I mean, it was 6.30. Splitting the apps could be quite beneficially and deploying the apps separately. So, one other thing is that we are now using third-party services for storage and a platform for deployment. We could also utilize a single platform for hosting both storage and for deploying the app. This could benefit network latency and more, and the app could operate more better and faster. So, collocating, let's say, the back end and the database service in a single platform could actually be beneficial. Another thing we also didn't pay attention when we started developing this was updating the dependencies which led to having some critical vulnerabilities on day one. This is a running young audit on the front end app only on day one when we actually launched the app. So, we already have vulnerabilities when the app was launched. So, it's worth taking note that introducing security into every step of the software development lifecycle now becomes clear that it's critical for development teams to invest in this. I think I recently read that some security scanning capabilities of the GitLab secure stage are also going to become available to the core editions. So, every developer can actually benefit from this. You can actually run static analysis for your code and actually see what's wrong with your code and improve it. Currently, we have some third-party services that provide monitoring and service monitoring pages. This is not actually fully descriptive. We don't have a clear view on the app availability or even the error tracking of the app. So, we actually don't have a clear view on this and this could be interesting to invest in monitoring and how we can actually track errors in our application. One other step is having multiple deployment environments. Currently, due to tire limitations of the platforms we picked, we had to only have one environment per merge request. Ideally, we could utilize review apps from GitLab to actually have a separate deployment for its merge request so you can actually preview the app live and that could help a lot during review time. So, what do we learn? I'll pass to Niky to take on with the last section of the slide. This is some things that we learn from this project and maybe some things that you can always implement in your own project. Firstly, when you start to work asynchronously maybe the to-dos, the notifications maybe seem overwhelming at the beginning. Don't force to prioritize everything when everything is important then nothing is important. So, take your time and respond when appropriate. At the first, you may seem that you're going slowly but in the long term you're going definitely faster and adopting a sync workflow takes time. So, be patient. Then, you have to be flexible in general. That means in a personal level give a chance to update your skills and this will definitely pay off in the long term. So, also be flexible and willing to adopt a new mindset. Don't stuck on the old things because it's evolving and you have to put the DevOps mindset when you start everything in code these days. Lastly, be flexible in terms of the team. That means building relationships on trust be kind to each other and show the gratitude when it's needed. Lastly, DevOps is the right way. Our advice is when you start every project give time to build a concrete pipeline and then focus on adding the core features. Having the right DevOps mindset will have a great impact on every aspect of your development process. This means agility, flexibility, consistency and of course, collaboration. Keep your team happy. Thank you George and thanks to everyone for your attention. If you have any questions feel free now to ask them or anytime during the event. George.