Get A Grip On CI/CD - Interview With Maciek Palmowski - Osom Studio - WordPress & WooCommerce Development Agency Of Choice

Get a grip on CI/CD – Interview with Maciek Palmowski

Enhance your company’s process and save money by implanting hassle-free testing. Listen to the conversation between Maciej Nowak, Partner at Osom Studio, and Maciej Palmowski, Development Advocate Analyst at Kinsta, about automation of WordPress builds – CI / CD.

Maciej: Hello everyone. My name is Maciej Nowak and welcome to Osom to Know podcast, where we discuss all things WordPress. My today’s guest is Maciej Palmowski from Bodyworks, and this episode will be centered around automation of website builds. , CI/CD is a broad topic that is recently gaining attention from WordPress World and I hope you will learn something from this for yourselves. And this is very interesting conversation for me personally because we worked with Maciej together in the past. So without further, do please enjoy my conversation with Maciej Palmowski

Intro: Hey everyone. It’s good to have you here. We’re glad you decided to tune in for this episode of the Awesome to Know 

Maciej: Hi, Maciej great to have you on the podcast. 

Maciek: Hi Maciek yes you too. Two Maciek is talking about technology. I mean to be honest, it’s also a great time for a podcast itself, right? Maciejs and technologies

Maciej: Yeah. Yeah. There are, there are two Maciejs and we worked for, uh, for, for quite a bit, um, together, and I think we’ve seen each other last time in Porto on World Camp Europe. Right? 

Maciek: Yes, exactly. We were trying to, to, to get some vegetables, uh, at, at the food court. It wasn’t easy . 

Maciej: Yeah. But it, it, it, it was still possible. So that, that, that was great. Yeah. Uh, so, so today’s episode is about continuous integration, continuous de develop delivery. 

Maciek: And development. Yes, because this is a very interesting abbreviation. We have this C I C D, and it means so many things at once, dependent on what you are doing. 

Maciej: Yeah so let, let’s, uh, tackle this. So what is C I C D and what, you know, what, what value can it bring to the, uh, to the company or to the team, or to the agency? 

Maciek: So, uh, first of all, let’s start with this abbreviation because, uh, like I said, it can mean quite a lot. The, it consists of two parts. First of it is the CI, which means always continuous integration and this means that every time when we change something in our code base, we run all the tests. So this means that we have to start working on our test suit in some way because, um, let’s be honest, testing our software each time by us humans is pretty boring, and machines love doing this because they love repeating the same stuff over and over and over again.

Maciej: I’m not sure if they love it or rather we make them do this. So it’s like our, our our doing that they love it or are capable of doing this. 

Maciek: I try to think that they really like the thing that they are doing because if not, I mean, it would be the first step towards the thing that happened in Terminator, right?They would rebel against us and we and we don’t want this. So, uh, I’ve tried to think that they really like, uh, doing those repetitive things and, um, we can concentrate only on things that, that matter. On the other hand, we have this CD part. Uh, there are few versions of what it means, but in general, uh, it’s either about a continuous development or continuous deployment, one means that, um, every time when this whole test suit, uh, gives us the green light, everything is okay. We are building our applic application and it’s ready to be deployed but a human being must press the button. Must say, yes, let’s deploy it. And when it comes to continuous deployment, as the name stands, we are deploying continuously. So every time everything went through, every time our code base on some selected branch is ready to go. We are deploying it automatically. Uh, this is very difficult to achieve because, uh, you have to be 100% sure about all your tests, about all your code base, about everything, uh, because there is no control about pressing the button. When to release if someone will push, uh, effects on Friday, and it’ll pass the test. It’ll get deployed. So if our testing suit is lacking, we just may destroyed our weekend for the whole, for the whole team. 

Maciej: Yeah. So, uh, about deploying on Fridays, we will get to that . Uh, what, what can go wrong, but let’s unpack the whole, uh, c I CD concept a little bit more. So the first stage, or the first phase is continuous integration. So there, there, there are the test, there is the code. Like creation and making sure this is passing the test and it, it’s working. So what are, what, what’s the alternative to doing this automatically? Because, you know, for example, we are, um, using, uh, C I C D, uh, as well in, in OSOM studio. And when I’m thinking if we can go back, it’s, it’s no option for me. So I cannot imagine a word without the whole suite of automation. But there is like a huge number of agencies or freelancer that still are not using this for their environment. So let’s compare it. What is providing, um, like see what CICD stack is providing for this stage versus what you have to do manually if you want to build something.

Maciek: Um, I mean, with building tests, there is one problem, and this is one of the reasons, one, why many companies say we are not interested in it. At the beginning, it’s a bit more work because you have to write some of those tests because there are two types of tests, those that only need a configuration file and those that require manually writing tests. So the second one will add few hours to your, to your work, and many companies will say, we don’t have time for it. Our budget, our budget. But on the other hand, the same company probably a month later, uh, while fixing, uh, many things on production because they didn’t tested it, will start wasting the budget they just saved. so, uh, trying to explain, uh, I mean, yeah, trying to say we don’t have time or money. In the long run? Mm, it’s, it’s a bit of a lie because, uh, in the long run, having at least some tests, some basic testing, uh, will always, always, uh, turn out to be something positive. Will. Will be a kind of huge gain for, for, for the company that that uses it. So, uh, every time when you think about, let’s not add testing because it wastes our time. Think again because like I said, in the long run. In the long run, so of course, yes, if you are doing, uh, micro project, that will take you an hour. Yeah. Probably adding test, it’s a bit of a. Of, of a stretch here, but the moment when you are building something with, uh, keeping this client for, for, for a longer time because you will be, I dunno, adding some new features over time and things like this. Uh, Adding some tests. It’s, it’s, it’s a master. 

Maciej: Okay. But you started this even one step before. So first of all, you have to decide if I’m going to do to run the test. So assuming, you know, you are now discussing if it is worth testing your software or not. So I guess, you know, we are past, past this, past this question. So there is the decision to do the tests and this falls into this, um, first stage or first, first phase where we integrate our software with new release. So, you know, in which situation, because this is interesting because this is like, um, Um, there, there’s that concept of C I C D. No ones understand and there can fall a lot of different, um, operations that can be automated. One of them are tests, but for example, where, uh, where, where, where, where ends continuous integration and where starts deployment. You know, deployment is easy if we, if we substitute d for deployment because this can be also delivered depending on who you talk with, right? So what else apart from the tests can you do in continuous integration? And maybe , I have the tendency to ask the wrong questions, so sorry about this, but you know, In order to work with C I C D environment, you have to think in this way that you are, you know, actually integrating some software. So this is a little bit different process than I start development. I, uh, shut the doors and then after two months I’m back with Ready Software. Right. So it, it’s a little bit of a different approach, right? 

Maciek: Yes. I would think of it when, when, when it comes to this, this whole CI part, I think of it. every time when you are doing something, if you see that there is a task, you start repeating automated just like this. I mean, it’s as simple as that sometimes. So if, for example, you see that, uh, every time you want to provide yourself a stadium environment, you have to download some files from somewhere, and you know that each time you are doing it manually. Adds one line to your, to your script, just. I dunno, using Curl or something else, just download those files and create a script. It’s all about, um, finding those things that you are doing manually and automating them. Uh, sometime ago I had a great conversation with, uh, with Christian Dango. He’s a specialist when it comes to. Uh, writing end-to-end tests. So those are when you are having your browser and you are in an automatic way giving it orders. Go here, click here, do something. And uh, he showed me, uh, how first they write uh, those automation scenarios, I didn’t know about this because, uh, when it comes to end-to-end testing, for example, first it’s all about writing scenarios. So there are detailed steps, what to do, and later, some of them are automated, but some of them require manual testing. But when you have a scenario, it’s so easy to follow. And this is a really, um, excellent example of when you have this scenario, it’s easy to either, uh, send it to some people who are, who are manual testers and will follow step by step to see if everything is working as it should, or to convert it to algorithm because, um, yeah, you have step by step, you have like literally described that go here. So we are just writing this for, for example, in Cypress. Go to this site, click here, click here. Each the, for example, some new new box should appear if it appeared perfect, test pass. If not, well not. And there is a lot of software, especially in the enterprise grade, that integrates those manual and automatic testing. This is also the thing you, we started talking about automatic testing, but there is still a lot of place for, for manual testing because there are things, um, that are quite difficult to end, to end test, have this tendency that they are, they sometimes give you false positives or false negatives. If you see that some test is falling quite often this way, this is, uh, this is the test that you probably will either have to rethink or just hire someone who will be checking this one thing. But it’s still about, uh, if you have like 2000 tests in general, , it’s still better to automate 900 or because I said 2000 or 1000. Yeah, 2000. So 1000, uh, 900, uh, and only have 100 to do, to have to be done manually. Rather doing every, every of them. So it’s also about some getting rid of some extra work.

Maciej: Yeah. Because, yeah, makes sense. 

Maciek: Yeah, because, uh, I, I know that’s the, the, the whole definition of C /CD kind of sounds scary, but if we, it’s kind of like in, uh, in, in Scooby and in, in the end of each, each, each episode, when they take off the mask of this monster, and it’s not a monster, it’s just a person. And with, with CI/CDD, it’s the same. It’s not something, it’s, it’s not some very complicated it concept. It’s just all about automating the things that we are doing manually. It’s not that hard. 

Maciej: Yeah. Uh, I think we always, uh, worry about our, our skirt, about the unknown and, you know, it’s umbrella. Umbrella term, CI/CD, and.That’s why I want, I want, uh, to unpack it. Cause I think it can bring so much value to everyone in the ecosystem of building software because this, this can bring value to the agency that can be more efficient and be less, uh, you know, error prone when, when building, um, websites but also to the client who, who can have, who can has own development team for the platform that they are doing and I guess that if you are not equipped if with C I C D, um, suite and building your website or your e-commerce platform internally, this is a huge, um, like red flag because if you have your own team and doing this, it means that you’re wasting every time you’re wasting time off your team or, or, and, uh, you are exposing yourself to, to problems because this is the, the area I like like the most. Let’s move to the deployment. So what can you automate regarding deployment so that this is, you know, very useful to the, uh, to the development team? 

Maciek: So there are few scenarios because, and this is also the cool thing it. It really depends on what we need. In the simplest scenario, when we have like a simple website and we work on a staging platform and on the production platform, it’s easy for us that we don’t have to remember to share all the passwords, all the logins to the whole team because the ci cd platforms provides auto deployments, uh, for example, on the staging side. So every time when we, for example, commit something to the deployment branch, the development branch it goes, uh, to our staging server, for example. Um, every time we are ready to go with the production site, we just press the button and it goes to the production. This is, this is cool, but this is simple. On the other hand, uh, one of the very important part, uh, especially right now because, uh, We are living in the era when we are constantly using, uh, some package managers, like Composer, like npm uh, Python has one of it. So like almost every, every modern programming language, uh, has a, has has a package library and we don’t put all those libraries into our repository. We just have, uh, JSON or Yam. It depends on the language file that, uh, consists of libraries we will use. And every time before the deployment, we will run, for example, NPM install or composer install or something like this. And we don’t have to worry about this and again, this is cool. This is very cool. It makes our work much easier and our repository is much cleaner, but on the other hand, we can go forward and. There are things like atomic deployments. So those are those zero time deployments. So, uh, the user on the, our viewer or our client won’t even see when the deployment happened. There won’t be any error, there won’t be any message like, sorry, we are deploying, maintaining time, or something like this. And, uh, atomic deployment is, again, this is a very cool term. That sounds a bit scary. But it’s just a list of procedures that we are just moving files into a one place. Then we are using the symbolic link. That’s it. It’s not as scary, but doing it manually, it’s, I mean, it’s boring. Let’s be honest. It’s boring. Most things about, uh, deployment, it’s waiting and doing few operations. It’s boring just like this. And thanks to automation, we can just press the button and go grab ourself. 

Maciej: Uh, I, would like. To stop here for a second and, and again, get back. One idea, um, you mentioned, uh, automation. You mentioned the process of automation for, um, dependency management. So, uh, referenceing all of the external libraries, and this is for our last technical listeners so that they can understand this better. So this is a process in which we don’t manual download all of the libraries. What you’re focusing on is indicating which libraries should be downloaded by the environment, by, by, by this tool. And this means for the, um, for the process that you are not doing this manually. So your developers are not wasting time and, uh, you are not doing this manually. So you are not, um, prone to errors, uh, doing this manually, moving files around. So this is both time saver and more consistent approach to managing your dependencies. So this is for Yeah. Do I get this right? Did they Yes. Exactly. Convey the message 

Maciek: correctly? Uh, yeah, because it’s all about, uh, having this big library of, uh, classes, files and everything, and not having to keep it in our, in, in our project, uh, in our repository, we are just pointing out, we want this version of, uh, this library, this version of that, and that’s it.

Maciej: Yeah, thanks. Thanks for this. And also the atomic deployment is very interesting for me because you mentioned this, it sounds scary for me. What sounds scary is not doing this in an automatic way because the consequences are, you know, if you have to shut down your website or turn maintenance mode on the website, this means you are not serving your visitors and this means you are not, for example, for e-commerce, like, Selling, you know, and, and this is directly impacting your business, depending on the business, of course, but also, you know, if you want to replace this atomic, because I’m, I’m always thinking like, okay, if not this, then what’s, what’s the scenario? What’s the solution? And if you’re not doing this atomically, like seamlessly, which is the, the, the best possible way you are either shutting down the website or doing this in, uh, because the transition moment is exposing yourself to unstable state because, you know, it says it’s, it’s a state machine there. So, so there is that part where switching is being inconsistent with the, with the files and then can be errors. And you can mitigate this by doing this manually, which can be automated with, uh, automatic de deployments. So I’m thinking what are the consequences of not doing this the right way and in times of, in, in a way that what you will sacrifice or, or what you have to spend to do this right. 

Maciek: Use a very good example of, uh, when it comes to cd. Thank you . Explaining c i cd and why it matters. Um, to a client that has a blog or a content site, it’s much more difficult rather than explaining it to a client that has a e-commerce side. Why? Because, as you said it, if the website isn’t working even for five minutes, We are losing money and this is the best way to convince everyone. And, uh, I mean, yes, we can, we can do it, uh, manually. We can, uh, do it without automatic deployments. Uh, but. Yes, but we, we will be losing money if we are having an e-commerce. So it’s, at this point, it’s more of a business decision. Do we want to lose money or do we want to, I don’t know, sacrifice or it’s not sacrificing because it’s more investing and our, of our developers to, uh, prepare our pipeline to, to work just like this. Or on the other hand, because. There are many services, for example, uh, amazing Beans Stack that will do it for us. We just provide them the files as a one big zip file and that’s it. They will take care of the rest. So, um, so like I said, it’s right now. Choosing between having C I C D and having those atomic deployments. It’s a business decision. Do we want to lose money or not? If we can afford this, okay, go for it. It’s, it’s your business, it’s your decision. But from the technical point of view, uh, Really automate stuff, and especially you, but you also mentioned one more, uh, very interesting thing about this state machine. This unstable state is something dangerous because you never know. I know , you never know what will happen because, uh, there is a possibility that for a second you will, for example, expose your password. For some reasons because for example, you have to security rules. Yeah, exactly. Because for example, you have to stop your server for a second because of something. So the second your server that your PHP server is not working. And if you, for example, have uh, WordPress site, if someone will enter the your WP config file and it won’t be per past SPH h p file, you will see everything. Uh, every time all those uncertain states, when you are not sure what can happen, we should avoid them at all costs because the surprises might be, uh, really terrible.

Maciej: Yeah. Uh, when, when you mentioned this, um, and when P H P can cause troubles, like, you know, um, five being not recognized as php, I have this. Mm, like analog idea. I mean, um, per idea of DNA replication and the most vulner vulnerable status when the DNA is replicating because this is prone to mutations and, and mutations can be very bad. Uh, of course they can be good because this is the evolution, uh, uh, you know, playing, but. , this is the unstable state. Uh, and, and we have to protect this, uh, because we can, we can be exposed for, for, for problems. But I’m also thinking, you know, there have to be, there has to be like a minimum Mm. Like, um, how to put it. Maybe if we shut down our website or e-commerce for an hour or for half a day, it won’t make a dent in, in our results. So there has to be a certain level when, where, where, where we start to care about the process. And as you mentioned, for block Owner, it might be the case because it is, for example, non blogger, lots of traffic, but traffic means ads. Or, you know, service ads. So, so this is also making, making, uh, impact, but maybe there is no, someone not known and this is not worth the effort. So, with this long, uh, intro, I want to say, I want to ask you, what’s the entry barrier? So, is there like a learning curve to this? Is it big or, you know, how much do you have to, you have to invest in order to use C I C D efficiently?

Maciek: Trying to implement the whole c I CD stack is difficult. Yes, it is. Especially that if you don’t have it, if you don’t have anything, you, uh, your website didn’t, uh, had any tasks, so. If we have something like this, implementing the whole C I C D methodology, it’s difficult. It’s very difficult. It’ll take a lot of time. But what’s important, uh, is to go step by step. The first and easiest way is to start with the with the deployment part, with automating at least some of it. So for example, let’s not keep, uh, our passwords and let’s not use FileZilla to deploy files. Let’s put everything in a GI repository. Let’s connect it with either, I dunno, body with GitHub actions with something like this. And let’s deploy it by pressing a button. next step. Automating all those build process, all those npm uh, round builds, npm installs. The same goes with composer. So every time we press run, more and more things happen. Uh, when we have this. , I would start with looking at your C I C D platform, looking what test it has out of the box.For example, if you are using body, you can uh, check your page speed, page speed score, or you can, uh, compare screenshots of before and after. It’s easy. You just provide a url. It doesn’t take time, and it gives you. A first layer of tests next them doing those tests that only require configuration when it comes to PHP world, because I’m,  mostly a PHP developer. Um, there are things like PHP stand, like php, uh, code sniffer, so you can check if your code is written in a correct way and thanks to PHP stand, uh, you can find a lot small errors, uh, just by, just by using one configuration file. It’s really amazing that the amount of work you have to invest in making them work. It’s like one hour and it’ll work every time, so every time before deployment. So maybe another way we did intro any test yet, and we were able to deploy, build, and, uh, check quite a few things already without writing any tests. So this is, this is amazing and there are, uh, applications, I think it, it’s called Ghost Inspector. It’s a very nice tool to start your adventure with and to end testing. It’s more of, uh, you write them by recording what you want to do. So if you know that you have, uh, on your website some crucial things like checking if your, uh, mail form is working or is adding to card working. Again, going to those, those e-commerce example, you just, uh, use ghost inspector, record your flow and it’ll check it every time. So, uh, again, we didn’t wrote a line of code and we were able to test quite a lot. So, but the most important thing is to add to, to do it slowly, step by step. Don’t rush because the moment when you try at some point in your company, okay, everyone, we are going CI/CD, full speed ahead. It’ll collapse. Everyone will be angry, everyone will be furious. It won’t work, and the only thing that you will do is waste, I don’t know, a few months or something, and you probably won’t achieve anything because, 

Maciej: and, and, and Goodwill as well. I guess because you, you, you’ll get burned and because if you are going, if you have a big, big team, let’s, let’s imagine you have your internal team for building, uh, e-commerce platform because we are e-commerce and you have internal engineers. Introducing this in a big organization, it’s like a change management. There will be always people who were advocates of the new idea, but also there will be people that are happy with the way the things are right now and they will, they will be resistance Sabo. Exactly. Resistance. Exactly, exactly. And you have to orchestrate the whole change, work with the people and, and make them believe in the idea and also in the outcomes.But it’s, it,, I guess this is. A process rather than operation, like atomic operation. Now we are doing the continuous integration. 

Maciek: Yeah, exactly, exactly. This is, that’s why it’s, IM important to understand the big picture, how it works, but really go slowly because it will be better even if it’ll take you more than a year, but you will implement most of it rather than after two months, you will just, uh, rise the white flag and say, yes. See, CI/CD sucks because, uh, no one wants to use it. Yeah, of course no one will want to use it because you try to implement it in the worst way possible. 

Maciej: Yeah. And, uh, from what I’m thinking about, like CI/CD, the, in my opinion at least, the best way to integrate this, like use this in the, in a way that it won’t break too many things at once, uh, is using this to deploy. Because if you’re, uh, an, an entity or agency or, or, or, or a company that already use, GIT Flow or, or another code repository, which is, I, I hope everyone listening, uh, is using, um, repository for you. Might be surprised. You might be surprised. I know, but it’s like wishful thinking from my end here. Yeah. But, but, but let’s assume you’re using, uh, repository to store your code. So, There is that possibility to automatically deploy the code once you are merging from development branch into master. So this is the ideally ideal mo moment in which your code is major enough to be deployed to the production environment and instead moving the device by hand. You can automate, automate it. Is this like, is it, you know, from your experience, is it a, a good moment or maybe there is some even lower hanging fruit to use as a first step for the listeners? Trying to think, okay, what’s in it for me? Where can I use it? 

Maciek: I think that, uh, the, the deployment part is, uh, is, is really the best because. The deployment part has, uh, one more thing. Um, the ef the, the effect of the deployment is real. You can see it, you just refresh the website and oh, it’s there. And when it comes to tests, yes, something passed terrific. I don’t get it. And deployments are real. So this is the first, the first thing, and the moment when you when you see how it’s easier to, because deployments give you many things for ex, like I mentioned, the security part. Uh, you won’t have to worry about, uh, giving away passwords or managing them because, uh, . If you, if, your employee just changes the job or you have to fire him, it doesn’t matter. You just deactivate his account in this, on the CI/CD platform and that’s it. You don’t have to worry about, okay, where was this password used? Who knows it? And, uh, I know some examples when sometimes I think that like hundreds of people already know the password to, to, to, to, to, to one of my clients, ftp because I know with how, with how many people he, uh, he collaborated and he didn’t think about using C I C D and, uh, At this moment, changing those passwords would be kind of, I mean, it, it would be an easy operation, but, uh, yeah, it would be funny. It would be really funny. , 

Maciej: but, but it also is the other way around. So for example, if you are an agency, different companies have different models, obviously, but if you’re in an agency and the given employee has access to number of website, This is also like centralized operation tool. Okay. Remove this access for that given person.

Maciek: Exactly, exactly. Of course. Um, the downside is every time when we centralize something, if the centralized part breaks for some reasons, we might, we might be in trouble, but, uh, Yeah, but still we have to, uh, again, this is, this is a decision we are making. It’s still better to centralize, uh, some things and have, um, and have it in, in, in control rather than give away everything to everyone and at some point try to figure out, okay, so who has what

Maciej:Exactly. And, um, is buddy using buddy for C I C D? 

Maciek: Uh, yes, of course, of course. I mean, uh, in, in, in, in, in general. Um, And the history of buddy is, is interesting because, uh, there was a product before buddy uh, I don’t remember it, it name it was, but I remember I tried to use it and it was a very good idea because it was, uh, something between, um, Asana or Trello, but together with all those developer tools like C I C D, but the guys quickly realized that, um, Yeah. It, it, it won’t work for, for, for most of the people. That’s why they just kept the C I C D part. And, um, I mean, still, still, I’m, I’m kind of surprised that there are so few applications like Buddy, when it comes to the UI and the ux. Uh, Thinking that most developers like to write everything in Jason’s or in yamo files, that’s not true. It’s, it’s, it is the same as saying that every developer, uh, only use GIT through the cli. That’s not true. , many of us preferred having a go and it, and the same goes here. It’s also, it’s much easier to concentrate on what matters. Right? Because we don’t have to, okay, so how, how was the syntax, how to write it? And we are just moving the blocks, clicking. 

Maciej: Mm-hmm. and what’s on the roadmap for buddy? what, what’s brewing for 2023? 

Maciek: Probably more and more, uh, integrations, uh, because, uh, Let’s be honest. Everything is changing so quickly there every day. A new JS framework. On the other hand, we are, uh, still working on, uh, on the actions related to end Android and iOS. So you will be able to build everything using body and it’ll be work, uh, much better. And uh, still we are polishing the sandboxes, so our. Environment to have, uh, staging websites inside of body. Mm. So more and more. Uh, so I think that it’s more the, the upcoming year is more about polishing what we already have, uh, rather than, uh, something new. But, uh, on the longer roadmap, uh, there will be really cool things coming, but, uh, The, it’s, a secret right now, . 

Maciej: All right. Sure, sure. But does this mean, does, does this mean that, for example, right now you were, it was focused for web tools only on, for, on web tools only. And now you will. No. 

Maciek: Oh, I mean, uh, we are focusing on everything because let, let’s be honest. When it comes to JavaScript, some things are already done. The foundation, and I mean, Big thanks to the whole JavaScript movement that. If you see most of the frameworks, they work the same. The deployment process is the same. So if we were able to, uh, create a process for one framework, we are ready for all of them. nd this is really great. And we are going, uh, with those Android and iOS because we heard, uh, from, from our clients that, uh, this is something they, they would like. They would like to have. Um, but we are focusing on, I think everything kind of equally, uh, for sure at this time because, um, we don’t, we, we, we don’t have to match, uh, iOS and Android developers, uh, is in, in our team. So it’s more about gaining experience and learning from, from other people. Uh, and so, so yeah, we are going, we are going quite wide. We are going quite wide. Uh, but still, because everything is based on, on Docker, if there is a docker image, you can try it. 

Maciej: Okay. Yeah. So there is a little bit of a universal, universal platform that you can build on, and this doesn’t mean you have to invest in every single direction, but rather utilize what’s already there and available.

Maciek: Exactly. All right. Exactly. And I, I, I really hope that, uh, after all those, uh, iOS and Android integrations, we’ll also have some time to invest more in those little tests that will run just out of the box because they’re so useful. They’re so useful because, um, like I mentioned, uh, it’s great to have the opportunity just to enter your URL or, or fire path and let the magic happens, especially when you begin your Jo Journey. When it comes to CI/C D, I know it’s, it’s. You just did your first thingk. Yes. It’s auto deploying. So let’s, let’s go further, let’s go further. And all those, uh, I’m, I’m, I’m a big fan of, uh, for example, this, uh, screen comparison action, uh, because it’s so easy to use, I know that it’s not the most powerful. There are much better scripts, but they require a lot of configuration. And here you just pass the url it works before the deploy. You can see that, oh God, the css we just corrected. It doesn’t work as we thought. Great. We just saved ourself from deploying a broken version. 

Maciej: Yeah. And there is that, um, very popular concept or visualization cost, um, that is generated compared to what stage. Something happens. So for example, if you’re prototyping, the cost is insignificant, then you have full design, then you have demo or, or mvp, and then you are on the production and the costs are, um, like crazy high, especially for manufacturing, manual manufacturing where you have physical product and you have to, um, get back all of like, like service action of Toyota brakes or whatever other car manufator. Has its, um, service action. So it’s, it goes in millions. In software, it’s a little bit easier because you can do this with one click you can correct stuff with one click. But if you have a flaw in, in, in, in the whole journey, for example, and you have to rework from UX perspective, something, this is very problematic with bugs, you know, this is also problematic, but it could be prevented.  And I think this is very interesting that CI/CD can help you automate, automate, preventing bad stuff happening. 

Maciek: Exactly, exactly. I mean, uh, during World Camp in part of, I had this, uh, these workshops about, uh, about automating deployments and preventing bad stuff happened, and I showed step by step. What we can prevent, which level of our code. And really, there are so many tests we can run and there are so many great applications that in that can help. Like this ghost inspector that I, that I mentioned, probably there are much more of them. Uh, but I also don’t know all of them because, uh, yeah, every day new application, new tool. We are really living in a beau in in beautiful times. It’s really so easy, uh, for us to, to be sure that our, that our website, our code, our application, whatever we are doing is working, is working, and we sh and I mean, it’s getting more and more difficult to find excuse. Why we messed up the deployment. Really, I, I have, I know it happens, it happens 

Maciej: still, but, but, uh, you know, at the same time, the users are not forgiving because it’s, you know, there is so much great design and great interfaces and usability out there that you have your expectations and if, if you are landing on a web shop that is providing great products at great prices, , if it is not also looking at least stable and not buggy. You know, this might be an indicator of a, of a scam, not a web shop, but of a, you know, a scam. So, you know, it, it, it is merciless. You have to be on the. On the edge of great, uh, product, whether this is a software, corporate software or web shop or application, web application. 

Maciek: Yeah, that’s, that, that, that’s true. I mean, this is one of, one of the reasons when every time I go to amazing, I feel like I just hate it. It’s, well, it’s cheap, even. I mean, yeah. I mean, this is for, for me, this is amazing how, uh, Such a company because let’s be honest, amazing. Doesn’t look really, I also think it’s not so easy to use for, for, for me at least, I dunno why. And every time when I land on Amazon, it’s like, No, no, I will probably It’s 

Maciej: by design. Yeah. But I, I, I, I’m looking, I’m looking forward to that book that will be written someday about, uh, amazing Amazon design. So what was the thinking? What were the tests run? Because I, I bet there are, There’s a ton of usability tests. I’m  pretty sure about this because they, they test everything and they have that user base that allows for, for testing. So I’m pretty sure this is all by design. And I feel you. I have the same feeling, like, okay, where do I click now?  I’m lost, right? 

Maciek: Yes. It’s, but on and it also doesn’t look good just like this. It’s not pretty. I know I, I know that there are more important things, but I know that this is amazing. This is a company that has like billions of dollars, so, No thank you. I will go somewhere else. I will find a product, uh, on, on, on, on, on a place that, uh, is more user friendly, at least for me. And I know that probably, I mean, I know that Amazing is doing everything for the ma majority of their clients. I am just not one of them. And okay, let’s go. 

Maciej: Yeah, that, that’s fine. So wrapping this slowly, um, Maciej is there anything our listen listeners can help you with or would you like to like say something at the end of the, of the recording? 

Maciek: Uh, I would, uh, like to say that at least give automation a try, really, uh, With automation. I mean, it’s  quite difficult to, to spread the word about it. Why? Because, um, I always say that automation is the boring glue that connects all the cool stuff. So, for example, we have our cool application that is written by our great developers using great libraries and on the other hand, we are using this magnificent hosting that has some amazing technologies and between. This is the CI/CD that is just moving one thing, testing it, pushing it to another, bridging the gap. Yeah. Let’s be honest. It’s. It’s hard to say yes. CI/CD is the most exciting thing in, in the release process because now it’s not. Uh, but still it’s so useful. It’s so useful. It’ll save you so much time. And, um, we discussed about those Friday deployments. at some point, I even wrote a small action that checks if it’s Friday. If it’s Friday, it breaks the deployment. It, it’ll.

Maciej: prevents. That’s nice. I love it. I love it. I have to introduce, I mean, we are not doing this on Fridays, but I think this is interesting Check if it is Friday, you shouldn’t be doing this. Or,  even thinking about this . Exactly. 

Maciek: Exactly. I mean, it runs all the tests. Every, I mean, you, you can put it. Any place you want. Uh, of course, uh, but I always thought of it about putting it just before the deployment, so they were let the test run everything. But the deployment, sorry, it’s Friday. Don’t do it.

Maciej: Yeah. I like the idea. I think we can make a, uh, a title of this episode, even . I will think about this. 

Maciek: I think that the title of the episode is, uh, today we have, uh, which day we have, uh, Tuesday. Right. So yeah, it was a very difficult Tuesday to record this podcast. Yeah. Yeah. We had so. Technical problems before, but, but we manage it. We manage it. 

Maciej: Yeah. Machi, thank you so much for having the time to record the episode with me today and thank you for listening. 

Maciek: Thank you. Have a great day everyone.

Intro: If you like what you’ve just heard, don’t forget to subscribe for more episodes. On the other hand, if you’ve got a question we haven’t answered yet, feel free to reach out to us directly. Just go to www.osomstudio.com/contact. Thanks for listening and see you in the next episode of The Awesome To Know podcast.

Next article

Being one step ahead of the WordPress core – Interview with Jakob Trost

Avatar photo

By Maciej Nowak

small logo of osom studio wordpress and woocommerce agency

Join Osom to know newsletter!

Get your monthly dose of WordPress information.