 Next up, I am excited to introduce Assad Raza. Assad has spent time in technical and leadership at several different startups. He's founded his own company and served in engineering leadership roles and also worked as a consultant where he has helped other companies build their software applications. So in his unique experience, he's been able to work with many, many other companies, especially startups and nonprofit companies, to help them tune and tweak their software development practices. And I'm excited for him to be able to share his experiences of the best practices he's learned with you now. Remember to hop into chat, ask questions of each other, and share your experiences as well while you are listening to Assad's stories. Hi everybody, my name is Assad and I currently run my own small consulting company. I am the current chief of that company. And the topic of my talk is to use GitLab as a default DevOps tool for nonprofits and early stage companies. So a little more about me, I've served as chief technology officer, I've served as a CEO of a couple of startups as well. And I've genuinely enjoyed the CTO role much better than that. And that's why I moved forward in doing that full time as compared to doing other roles. So my company, current chief.com, basically we consult nonprofits in their digital transformation and all of this, I chose this direction based on my previous experience in the area in my previous companies. Since 2013, since I started working professionally, I've launched over 50 software applications where some of them were got featured into App Store and Play Store. Some of the applications also had millions of users and some are still being used by hundreds of thousands of users right now. So when I started working professionally, DevOps looked like the wild west. So basically people were just pushing files directly into servers using clients like FileZilla and it was pretty much a mess and Git or Mercurio or any version control systems were not well adopted. So it became a really pain to actually review other people's code. It became a pain to actually have any conflicts in the different files that a few developers were working on. So eventually when things started getting better and in a few years we started using multiple tools for each part of the DevOps process. So we had multiple tools for building, for coding, for testing and for deploying. Eventually what happened was that once the space got hot, everybody starts jumping in and then the space started looking like this, which meant that it became impossible to use different tools. If you're a consulting agency, each client had different requirements. So you pretty much had to learn each and every tool and there were so many configuration problems with tools as well. So one tool would get updated or something would change and because of that you would have to change your configurations and your connections with different tools as well. So CI, CD or DevOps for the whole process became a mess. So some of the apocalyptic scenarios that I've seen and witnessed during these years was that basically people would push a change and it would just break down and we would not know where it broke down. So basically as we all know as startups or even as big companies, according to Parkinson's law that work expands so as to fill the time available for its completion. So basically even if you're a small company or a big company you would eventually try to ship any features at the end so you can either show your investors, your new customers or your existing customers as well to get their premium memberships. So one of the funniest stories that I came across was basically I was on a stage in New York at a big conference in front of 2000 people three, four years ago and our login feature broke down and the phone number field was not working when we were adding our phone number for verification. This caused a lot of embarrassment and we pretty much lost that pitching competition as well basically because of that. And eventually I also saw configuration issues and there were a lot of issues for human errors. Obviously who would work on compiling all of these tools or configuring all of these tools together would have to give a great amount of detail on each and every step of the process. So my first reduction with GitLab was not as a DevOps tool. I saw a Y Combinator talk a few years ago where GitLab CEO was telling how he manages his 100% remote company and I became curious and saw that people were actually pushing changes to the handbook or GitLab employees were basically pushing changes to the handbook which I found super funny because they were making their non-practice people also use Git as well. Furthermore then later I started using GitLab initially for repositories and eventually once I became more and more proficient in it we started using it for a complete workflow. And right now GitLab is the only tool that I use for my own work because it makes everything super easy and there's only one point of failure. So before we actually go to what GitLab provides for a small company or a non-profit with low budget for technical themes, some of the problems that happens with multi-tool approach is you can't stay lean. So if you have multiple DevOps tools on different stages there's a very low chance that you can find somebody who has an expertise on those tools and can debug it like an expert. Furthermore hiring becomes a problem because the budget is low for us, for small companies and somebody who has that kind of knowledge is operating at the top of their game so it becomes very hard to hire them and compensate them accordingly as well. Furthermore there's so many failure points because you'll connect tool A to this, tool A to deployment, tool B to development, tool C to testing and these multiple failure points makes it hard to actually debug code or fix issues in production as well in case there's some apocalyptic scenario. So the biggest advantage that I found on GitLab was it took me like two weeks to figure out everything regarding the CI CD or the whole CI CD pipeline how I can run different jobs on different environments and then it became like super mainstream and it became very easy for me to handle everything. Furthermore it became very easy for me to also train talent as well so instead of trying to train people on different tools GitLab was the only go-to place for pushing their code for testing their code for deploying their code. Furthermore in case of bugs or anything we had single point of investigation which made it much much easier as well and in case of failure there was less downtime because we only had to go to GitLab for a problem. Furthermore for product managers and other non tech people that I work with GitLab's UI makes it very easy for them to visualize how the whole development process is working and how the whole DevOps process is working. As compared to they have to go to the CI CD configuration and see how these different jobs are running so that makes made it really easier and also made us explain that why we are using GitLab to our customers as well. So these are a couple of reasons that I transformed my previous companies and my current agency using DevOps. So everyone should be able to use GitLab and create a simple pipeline no matter if you're a UI UX designer with some programming background, you're a product manager, you are a front-end developer. No matter whoever you are this is my rule number one. The second and everyone should be able to debug and resolve simple issues as well. So if you create a simple pipeline you should be able to resolve issues for that as well. Furthermore one of the things that became really important and really apparent in the end that you need to have a clear branching strategy and you need to have each branch or each environment completely separate from each other and and involve a key person in between each environments for that. So basically when we are building systems which is more critical and we can't afford any errors so I use this four branch strategy for development for testing which includes manual testing and automated testing then you know you do a UX testing on the live branch before you move it to the main branch which is the customer facing branch and this has helped us reduce a lot of UX errors, a lot of problems with the code as well and it has never occurred to us by following this strategy that there are any errors in the main branch. Furthermore we need to document each step of the workflow as well and this is also based on a number of experience working with remote freelancers working with my own personal team that you need to have a first round of QA each person who is responsible for that environment needs to give proper version tags and a version tags on it as well and this is one of the workflows that I was working with my previous company so basically our development and test environment was on a staging server and our live and main environment were on the live server connected with live APIs so we can also have dress rehearsals with our new customers or our new vendors on the live server but on the live environment so if they commit a blunder or something or there's some wrong data that they upload the end user might not see it so this is one of the others our system architecture diagram and how to have our the first step with the development staging branch that is connected to the test server the main test branch is also connected to the test beta base and server as well final QA branch and final main branch both have live servers on it so users or testers are involving themselves or are communicating with the live database and the live data so I was really interested in how much time GitLab or any single software suite saves you and based on my calculations GitLab has reduced our deployment time by at least 75% it has reduced our pre- and post-mortem time from days to hours and especially after we do a feature it becomes very easy to see what kind of code quality was maintained what kind of tests were written based on GitLab as compared to other tools furthermore it enables continuous improvements in the product as well and in some of the scenarios when we start our meeting for the product demos it used to happen that we would fix that issue in the meeting and then publish it and ship it out to the deployment server within that meeting and some of our clients were super impressed because of that as well furthermore we were able to involve using GitLab UI we were able to involve the product team and the product project stakeholders into the dev house process as compared to the assuming we are using as compared to the assuming we're writing some source of some sort of a magical code to do all of those integrations in the in our product so basically while starting GitLab CI CD we had a lot of confusions we had a lot of confusion because we used multiple tools configuration having multiple configuration issues and eventually while we adopt CI CD to GitLab CI CD to as the main CI CD and the only single DevOps tool everything became super easier and it was very easy to become an expert expert in one tool which makes debugging your issues faster and easier as well so that is it