Asad Raza – GitLab, The Go-to DevOps Tool for Non-profits and Early-stage Companies

Next up, I am excited to introduce Asad Raza. Asad has spent time in technical and leadership at several different startups. He started 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 in a chat, ask questions of each other and share your experiences as well while you are listening to Asad's stories.

Hi, everybody, my name is Asad, and I currently run my own small consulting company, I am the commander in chief of that company and the topic of my talk is to use GitLab as a default Devops tools for non-profits and early stage companies. So a little more about me, I've served as chief technology officer, I've served as CEO, a couple of startups as well, and I've genuinely enjoyed the CTO role much better than that. And that's why I move forward in doing that full time as compared to doing other roles.

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 lost over 50 software applications where some of them got featured into App Store and Play store.

Some of the applications also had millions of users and some of them 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 into directly into servers, using clients like file zilla. And it was it was pretty much a mess and git or mercurial or any version control systems were not well adapted.

So it became really pain to review of people's code. It became a big 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 of the Devops process.

So we had multiple tools for building, for coding, for testing and for deploying. But eventually what happened was that once the space got hot, everybody starts jumping in. And then the space shuttle started looking like this, which meant that it became impossible to use different tools.

Each of if you're a consulting agency, each client had different departments. So you pretty much had to learn each and every tool. And there were so many configuration problem with the 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 or the whole process became a mess.

So some of the apocalyptic scenarios that I've seen and seen and witnessed during the years was that basically people would push code 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 two thousand people three or four years ago. And our login feature broke down and the phone number field was not workin and we were adding our phone number for verification.

This caused the embarrassment and we pretty much lost that pitching competition as basically because of that. And eventually also I also saw configuration issues and there were so many there were a lot of issues for human error. So anybody who would work on compiling all of these tools of configuring all of these tools together would have to give a great amount of detail and each and every step of the process.

So my first interaction with GitLab was not as a Devops tool. I saw Y Combinator talk a few years ago with GitLab CEO was telling how he manages his 100-personremote 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 tech people also using it as well.

Furthermore, then later I started using it and 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 there's before we actually go to what GitLab provides for a small company or a nonprofit with low budget for technical teams, some of the problems that that happen with multi-tool approach is you can't stay lean. So if you have multiple Devops tools and different stages, there's a very there's a very low chance that you can find somebody who knows who 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 that 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 can actually do this to A to A to deployment, to B, to development, to 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 there is 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 CI CD pipeline, how I can run different jobs on different environments. And then it became like super mainstream and 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 the record, for testing the record, for deploying the code. Furthermore, in case of bugs or anything, we had a 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 people that I work with, GitLab 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 it really easier and also made us explain that why we are using GitLab to our customers as well. So how so this is 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 programing background, you're a product manager, you are a front end developer -- no matter whoever you are. This is my rule number one. 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 each environment 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 do a UX testing on the 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 a lot of problems with the code as well.

And then 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 first round of QA. EAch person who is responsible for that environment needs to give proper version tags and 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 testing where was on a staging server and our live and our live and main environment were on the server with connected with laptops. So we can also have dress rehearsals with our new with our new customers or our new vendors on the server, but on the environment.

So if they can 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 the first step with the development staging branch that is connected to the server, the main test branch is also connected to the test database 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 integrate are communicating with the database and the data. So I was I was really interested in how much time GitLab or any single software suite saves you, and based on my calculations, GitLab is reduce our deployment time by at least seventy five percent. It has reduced our pre and post mortem, 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 good quality was maintained, what kind of tests were written based on GitLab as compared to other tools. Furthermore, it enables continuous improvement 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 why we were able to involve the product team and the project stakeholders into the Devops process as compared with they assuming we are as completely assuming we're writing some sort of some sort of magical code to do all of those integrations in the our product. So basically, while starting GitLab CI CD, we had a lot of confusions we had a lot of confusion because we use multiple tools, configuration, having multiple configuration issues, and eventually while we adopted CI CD to GitLab CI CD tool as the main CI CD and the only single Devops tool, everything became super easier.

And it was very easy to become an expert in one tool which makes debugging your issues faster and easier as well. So that is it.