Transcript
Speaker: Hello, hello.
Speaker: It's Artistry of Code again.
Speaker: This time our hosts are Artur Wolny, Grzegorz Godlewski, and Marek Ulmanowicz.
Speaker: Hi guys.
Speaker: Today we gathered to talk about continuation of previous topic.
Speaker: So last time we talked about continuous integration.
Speaker: This time we go one step further to the deployment phase.
Speaker: So continuous deployment is our topic.
Speaker: Welcome to the Artistry of Code podcast where we, together with our guests, are seeking ways of doing things right and having fun with it.
Speaker: Software, architecture, soft skills, teamwork and other crazy buzzwords.
Speaker: Are you ready?
Speaker: Let's bring more value to the business.
Speaker: But before we start, our dear listeners, please make sure that you follow our show on Apple Podcasts, Google Podcasts, Spotify.
Speaker: Don't forget to subscribe to our channel on YouTube and hit the like on our fan page on Facebook.
Speaker: Okay, so let's proceed to our topic.
Speaker: The best would be to start with the definition.
Speaker: So how do we define continuous deployment?
Speaker: Grzesiek, do you have an idea?
Speaker: Yes.
Speaker: So for me, continuous deployment is essentially a practice in which the code is automatically deployed as frequently as possible.
Speaker: And in the simplest form, that's actually upon each and every commit, at least for the main or master branch, depending if you switch to the naming already.
Speaker: So typically for myself, I have continuous integration pipeline set up for things like
Speaker: feature branches, things like that.
Speaker: And the continuous deployment step is being done on the main or the master branch.
Speaker: And I also tend to split this into two parts because I'm deploying stuff automatically to staging.
Speaker: And then I'm using a manual promotion mechanism.
Speaker: So once I'm done with testing what I've deployed in a continuous fashion and I decide that this is okay to go there to the public, I'm having a separate promote button, which is going to push that code to that next environment.
Speaker: So that's it for me.
Speaker: Artur, how about you?
Speaker: For me, it's more like by the official definition.
Speaker: So the continuous deployment is approach to deployment that is targeting fully automation of that process.
Speaker: So every time the integration of application ends and we have some kind of artifact that can be deployed,
Speaker: the automatic pipeline jumps in, does the job by deploying it to another environment that we have defined in our process.
Speaker: does it automatically.
Speaker: That's the most important thing.
Speaker: And second, between those deployments, there are executed a set of checks that are about to ensure that everything works as expected.
Speaker: So that's making the process safe.
Speaker: While we're recording this episode, outside of my window, I can see the continuous delivery of the snow.
Speaker: So it's a bit scary what I will see when I leave the house.
Speaker: But going to the topic of the continuous deployment, to me, it starts before merging to main.
Speaker: So it's a bit different to me, comparing to what you mentioned, Grzegorz.
Speaker: Because to me, everything should be always tested before getting merged, but it obviously depends on the project.
Speaker: But this is like the perfect situation to me.
Speaker: And that's why the continuous deployment starts there to me, because...
Speaker: when we want to really test something manually, because we know that not everything can be tested automatically or at least not at reasonable cost sometimes, and we want to do some manual QA.
Speaker: processor, it needs to be deployed in one way or another to something which sometimes is called preview environment or something like that.
Speaker: And that's what should happen with continuous deployment to me also on the PR stage.
Speaker: And then after everything is done and we are good with testing, we are happy with the quality of the change, we merge it after all the testing automated and manual is done.
Speaker: So that's where I already see the continuous deployment part.
Speaker: And yet then the continuous deployment on main is exactly what you guys already explained.
Speaker: And I don't see anything to add, to be honest.
Speaker: So I think we can go further to not repeat stuff.
Speaker: Yeah.
Speaker: So now we can ask a question.
Speaker: What the continuous deployment can give us?
Speaker: What are the benefits that it brings?
Speaker: And this question I will try to start answering myself.
Speaker: I have always been a fan of Kanban.
Speaker: So for me, the continuous integration, then continuous deployment is somehow a continuation of the Kanban board.
Speaker: So you have another, let's say, steps in your pipeline that can be even...
Speaker: visible on the Kanban board.
Speaker: It can be done, for example, even in Jira by automated moving of the tasks between another columns.
Speaker: That's at least what we have already in Frontex.
Speaker: It works pretty well.
Speaker: And if
Speaker: If you are familiar with Kanban, Kanban defines two important metrics that should be measured to check if the team is proceeding in a good direction, if it's like...
Speaker: working better or worse.
Speaker: So this is cycle time and lead time.
Speaker: So I will not speak much here about the definitions of those, but the continuous deployment is
Speaker: is decreasing the lead time and cycle time because it makes it automated just when the work of the developer and tester is done.
Speaker: The process is automated, does not consume anyone's job.
Speaker: It's not vulnerable to
Speaker: the people forgetting about things, the people waiting for something.
Speaker: It just starts.
Speaker: The pipeline goes as fast as it is possible at the moment by the hardware that is available.
Speaker: And the shorter lead time and cycle time give us also faster feedback from the market.
Speaker: So sorry, Grzegorz, for taking this point from you, but it's so correlated that I needed to mention it.
Speaker: So, yeah, we have things on the production faster.
Speaker: And this way also not only the team is satisfied with it, that people don't need to do the repeatable jobs, which is boring, but also for the business that just has its requested features faster on production.
Speaker: I would like to mention some, let's say, soft stuff, which is, first of all, it's super simple, but beneficial, I think, which is clear status of the task to the PMs or whoever from the business side.
Speaker: So with the CD done properly, the
Speaker: Project managers don't have to keep asking when we will have it on prod or do we have it on prod already?
Speaker: Because if it's done properly, some sort of webhook will automatically switch the status, which we all love for sure, of the task.
Speaker: And yeah, that's it.
Speaker: And no asking, no pinging, which is always annoying for both sides.
Speaker: So that's definitely one benefit for everyone, I think.
Speaker: The other thing, which is, in my opinion, maybe not often that obvious, is new employees onboarding with CD in place.
Speaker: Because when someone is joining, especially someone maybe more junior level, it's really hard to, it was maybe, or it is for some companies not using CD still,
Speaker: in 2022, to onboard someone to get them having the changes deployed because they cannot just deliver the code, get it merged after the review, and yeah, that's it.
Speaker: They would have to be onboard to the deployment process
Speaker: probably, or they would have to go asking the DevOps somewhere through the Slack, which is obviously annoying and also time consuming.
Speaker: And people are not always like super open.
Speaker: So that can be also like challenging on the personal level, etc, etc.
Speaker: So that's a big benefit, I think, to me.
Speaker: And also I see the good cost saving.
Speaker: At least it is possible to cost save on the CD in long run because if the CD is done properly, we usually won't need DevOps if we don't overcomplicate it, obviously.
Speaker: Because if we will overcomplicate it, we will need DevOps to fix this in long run anyway.
Speaker: But yeah, there is possibility to cost save on CD as well.
Speaker: So I'm not mad about taking that point, Arthur.
Speaker: I would just add to that faster market feedback that, yes, you're right, the lead time and cycle time shortening optimizes the delivery time, like overall delivery time.
Speaker: That was really important to emphasize is that once that change hits production, the users start using it from the moment it's there, and then the business gets that
Speaker: feedback loop activated.
Speaker: And this can already influence the next iteration if you're working with iterations.
Speaker: And that's a very valuable thing.
Speaker: About the cost saving and time saving, we just can be a little bit more explicit and just point out that most of the time it's saving developers time and operations time.
Speaker: For me, setting up CICD is one of the first things to do when you're running a greenfield project because then from day one, I have all the deployments in place and I don't care about this till the end of the project, really, or unless there's a
Speaker: change in that pipeline required, but it's benefiting me from day one and I really love to have it.
Speaker: The other benefit, which is also inherent in using a continuous deployment, is that it promotes smaller changes.
Speaker: So I'm personally a fan and an advocate of an approach where you do one change to production at a time.
Speaker: So each and every bigger change is like decomposed to smaller changes and we deploy that.
Speaker: And the benefit of this is that it's actually helping you to manage the amount of potential damage at the end of the day, right?
Speaker: Because if you're going to roll back that deployment, you're going to roll back that particular change, which is going just to limit the havoc really.
Speaker: Okay, to this point, I would like also to add the security concern.
Speaker: So this is something that you have reminded me, Marek, when you were talking about onboarding people.
Speaker: So with continuous deployment, you have all the credentials required to put the code on the production, actually stored behind some kind of information
Speaker: wall in the application of the application that does the deployment.
Speaker: So you don't need to give any
Speaker: credentials to the production to people, which may be risky in terms of some security breach, data lost, data leaked to the internet because the less people have access there, the better.
Speaker: So it's more secure for sure.
Speaker: Okay, so we mentioned a lot of benefits of continuous deployment, and I hope that you will be convinced right now if you have been hesitating to introduce it into your company.
Speaker: So next, we need to know that it comes with challenges and some requirements needs to be met to start with continuous deployment.
Speaker: implementation.
Speaker: So maybe let's talk about it.
Speaker: What do we need to have?
Speaker: What challenges we need to overcome?
Speaker: I would start from the point I already mentioned about the preview environments or QA deployments, whatever you call it.
Speaker: And depend on the product, it comes with different challenges.
Speaker: Some products can be super easily be deployed for preview or QA.
Speaker: But as soon as you get some kind of external dependencies there,
Speaker: Maybe not that easy to either mock or just use them for QA.
Speaker: It can be sometimes hard.
Speaker: So I mean, sometimes it's just about the infrastructure.
Speaker: So maybe some cloud products which we have to deploy.
Speaker: Maybe sometimes they are, even if it's not that hard to deploy them with some tools, it can be expensive to deploy them.
Speaker: So we may not want to do this kind of stuff for QA.
Speaker: Also, if we talk about the payments, it is always challenging to use it on the QA stage.
Speaker: And even webhooks are sometimes hard for the QA environments because you have to somehow attach it.
Speaker: this QA environment to the QA environment on the dependency site, like the payment gates or something.
Speaker: So this is for sure a challenge here.
Speaker: The other thing is...
Speaker: To me, the critical part which comes with the CD is the monitoring and observability of the product.
Speaker: So when we deploy, to me, there is no CD without the monitoring.
Speaker: So it's pointless to continuously deploy if you don't monitor it in one way or another.
Speaker: So sometimes you can even go farther with the CD implementation there.
Speaker: And after it's being deployed, inside the pipeline, it's monitored.
Speaker: And in case of some failure, it will be automatically somehow rollbacked and reported and everything else.
Speaker: So yeah, these two things are critical to me.
Speaker: So this also has been raised today a number of times.
Speaker: Solid test suite and really good CI implementation.
Speaker: This is a very important prerequisite.
Speaker: So it's not about only just testing things before deploying or during the build of the code, but after doing the deployments.
Speaker: And here we have a couple of types of tests, really.
Speaker: You can test the whole product with any sort of like
Speaker: regression or automated testing, like small testing, if you wish to do so.
Speaker: But it's also worth mentioning that the tools which you're using frequently also provide you with some means of executing tests against the environment.
Speaker: So for instance, Helm, we're going to get to the tools in a moment, but just to point it out, Helm has a possibility to
Speaker: define tests for a deployment.
Speaker: And then once that deployment is applied, Helm is running those tests and it may automatically roll back the whole deployment if the tests fail.
Speaker: And that's as part of Helm's operation.
Speaker: So it's not like another step in the design of the pipeline.
Speaker: It's just reusing the power of the tool, which is already there.
Speaker: And one additional requirement, which I would point out, is using feature flags.
Speaker: Because if you're deploying things continuously and you're deploying, like I do it in, let's say, commit by commit mana, then at some point you're going to have some sort of like working progress happening there.
Speaker: So you'll be doing changes, but you don't necessarily want to expose those changes yet.
Speaker: And this is the place where the feature flags come in handy so that you can flip a switch and hide this prod environment, but on the other preview or staging environments that's going to be enabled so that this can be verified, tested, etc.
Speaker: And how about you, Arthur?
Speaker: I think that we have been talking a lot about some technical stuff, but I feel like also the approach to delivering another smaller chunks of code is required.
Speaker: So you need to have this continuous integration culture, not only implementation in the pipeline to
Speaker: even be able to deploy those parts of your code that do not introduce some kind of user feature.
Speaker: Sometimes you need to partially deploy just to follow with the continuous integration of small changes implemented in a way that it will not break the system, even though it does not fully introduce the feature.
Speaker: So feature flags can be handy here, but in general, I believe we should have a mindset to create small chunks of deployable code.
Speaker: I would like to just add some benefit of the feature flags because I love them.
Speaker: And feature flags are often also the lifesaver because it gives the possibility to some kind of soft rollback.
Speaker: So you don't have to roll back everything and you can leave it maybe for some targeted testing because you can enable it just for maybe your company users.
Speaker: or something just to maybe dig more into the code because maybe on any of the previous environments, it doesn't happen.
Speaker: It doesn't occur, this bug.
Speaker: And you have to, unfortunately, find the bug in prod.
Speaker: And this will allow you to do it, investigate it without hurting the customers.
Speaker: So this is one of the big benefits, I think, of the future flags.
Speaker: I would like to come back to the approach to the work matters.
Speaker: So I feel like it's also important and important requirement in introducing continued deployment.
Speaker: Very similar to introducing continuous integration is the trust that needs to be built inside the team and also between the team and some business representatives, either product owners, product managers, and
Speaker: whoever it is, because we live this process of putting things on the production to some heartless automates that operates according to those strict rules.
Speaker: And it is harder for automated tests to find some unusual problems, which we people are good at.
Speaker: So summing up.
Speaker: We need to get trust and then is the good time to continue with automated deployment.
Speaker: Okay, I feel like we've mentioned a lot of challenges already.
Speaker: Probably there are more than we mentioned and we hope to see them in the comment section under the recording.
Speaker: So now let's proceed to tooling that we can use for implementation of continuous deployments.
Speaker: Do you guys know or have experience with something?
Speaker: I will start here as Mr. Complainer and I will mention stuff which I would like to avoid doing so on CD part.
Speaker: And this is something which is often available on different sort of tools like for example, multiple Azure products allow you to enable continuous deployment
Speaker: from the admin panel.
Speaker: So it's super easy because it can be done in UI by connecting the product to the repo.
Speaker: And it's not only about Azure because many, many products to do so.
Speaker: And this is like super unsafe to me.
Speaker: And I would discourage everyone to use it for stuff which is like business critical.
Speaker: It can be used for some hobby projects to like speed things up.
Speaker: Maybe at the beginning, if you don't have experience with proper CD, but not for some business serious stuff.
Speaker: Because it's not then the part of really the pipeline.
Speaker: As soon as something is merged,
Speaker: on the main branch, for example, it will be automatically deployed.
Speaker: And you don't see that the status of the deployment on the pipeline, which we sometimes, hopefully at least as developers, check if everything is green.
Speaker: So you don't have this feedback.
Speaker: You cannot give some preconditions to this deployment because it's just merged, okay, deploy.
Speaker: You are not able to give some preconditions like maybe some quick tests or whatever before the real deployment happens.
Speaker: So this is kind of tool which I would say not to use as part of CD because it's not the part of CD in the end.
Speaker: Yeah, Marek, you mentioned a very important thing to rely on the single pipeline rather than some events that happen in the system automatically without our control.
Speaker: So because it is pipeline, I see it as a continuation of continuous integration.
Speaker: And this is why I see it as a possibility to use the same tools that we use for the continuous integration.
Speaker: And usually it is.
Speaker: So you can deploy right now using the CircleCI.
Speaker: You can use the GitLab CI slash CD implementation.
Speaker: You can use Jenkins even if you still have it in your organization.
Speaker: So there are lots of tools originally used for continuous integration that can continue the pipeline with the deployment, because it's another steps on the way.
Speaker: So as it was in this continuous integration, you can here refer to our previous recording, it is still a set of some executables run for every step.
Speaker: So to deploy things, it's usually not done by the CI pipeline tool itself, rather by those executables that we need to have.
Speaker: So for example, we can use infrastructure as a code solutions here.
Speaker: So Terraform can be handy if we would like to...
Speaker: also set up some other dependencies, other services.
Speaker: For the deployments on Kubernetes, we can use Helm and its charts, which according to 12-factor app also should be placed in the same repository.
Speaker: So the code should be there.
Speaker: The definition of charts should be there.
Speaker: So they can be easily...
Speaker: and the configuration from how charts can be easily put into the Kubernetes cluster.
Speaker: And there are also some things that
Speaker: that gives us some kind of visibility about the deployments that happened.
Speaker: And my favorite here is the Commodore, which is a third party service.
Speaker: You just buy it, configure it to have access to your cluster.
Speaker: And the Kubernetes is some kind of GUI for the kubectl command.
Speaker: It has similar possibilities.
Speaker: but it also introduces your users some limited privileges.
Speaker: So your developers can have the visibility options of KubeCTL.
Speaker: So see if it deployed, if everything,
Speaker: is working after the deployment, can see the history of deployments, how the pods reacted, can pick logs of single nodes, but for example, can't kill the pod or do something that we might want to strip from his privileges.
Speaker: So this is my set of tooling.
Speaker: Grzegorz, do you have yours favorites?
Speaker: Yeah, so what I frequently tend to do is depending on the context in which I'm operating.
Speaker: So when I'm using big bucket pipelines, I have different options.
Speaker: If I'm using GitHub Actions, I do have other options possible.
Speaker: Since my favorite platform to deploy apps, at least for my private projects, is Heroku.
Speaker: Heroku provides something called Heroku Deploy.
Speaker: And if you would like to make use of that or this kind of tools, essentially, I urge you to check your pipeline provider set of plugins.
Speaker: Because it's a very common thing right now that different platforms do provide some specific plugins for their platform to deploy stuff either from GitHub or even from Jenkins.
Speaker: So your cloud provider probably has a plugin for your CI solution where you can plug this in.
Speaker: So my personal favorite is Heroku when it comes to that.
Speaker: But in your case, that might be different.
Speaker: take a look at the documentation and the plugin set, there might be something useful.
Speaker: One recommendation which also just popped up in my head was, Artur, you were talking.
Speaker: I do recall one practice which we had, which was that we were separating the pipelines from one another.
Speaker: So there was the CI pipeline building the application itself, and that was like a finishing off with the artifact, like a Docker image,
Speaker: or a terrible file with the source code or the result code.
Speaker: And then there was a separate pipeline specifically for deployment, which was bound to a different repository, not the code repository, but rather configuration repository.
Speaker: So there are two flavors of doing the CD.
Speaker: You can either have it on the very same pipeline
Speaker: or as two separate pipelines.
Speaker: Each and every of those has really their own benefits and drawbacks, which you have to consider.
Speaker: But we're not going to cover this on the episode, just mentioning for reference.
Speaker: Splitting the pipelines is usually really beneficial when you have to comply, for example, with ISO, which was the case in our case.
Speaker: So that's useful to avoid like super, super long pipelines, which are impossible to monitor.
Speaker: Yeah, that's true.
Speaker: We remember that all.
Speaker: So, yeah, guys, I feel like we run out of our points for this topic.
Speaker: We mentioned lots of benefits, challenges, and tools that we used to use in our experience.
Speaker: We know and sometimes even like.
Speaker: But now it's also the part for you, our listeners, to share your stories, your experiences with continuous deployment.
Speaker: Maybe share with us some tooling because right now the continuous deployment area and continuous integration also is developing so fast that we can't follow up on ourselves.
Speaker: There's lots of new stuff going on in this area, lots of new tools introduced, which are meant to
Speaker: make our life easier and safer.
Speaker: So thank you very much.
Speaker: And that's all in this episode.
Speaker: Don't forget to leave your comment.
Speaker: Don't forget to like our fan page.
Speaker: Hit a like also on our videos, recordings, and see you next time.
Speaker: Bye bye.
Speaker: Bye bye.
Speaker: Take care.
Speaker: Bye bye.
Speaker: That's all for today.
Speaker: Thanks for spending your time with us.
Speaker: Visit our page on Facebook and Twitter, leave us a comment under the episode, subscribe to the updates and share it with others.
Speaker: We would like to hear your feedback so that we can prepare more interesting content for you to enjoy.
Speaker: Hear you next time!
