Devtron - Kubernetes-Native User-Friendly CI, CD, and GitOps

this is how you combine continuous integration continuous delivery and git tops in a package that is kubernetes native applies modern principles and is user friendly if somebody would ask me hey what would be your recommendation for continuous integration continuous delivery git tops all of that running in kubernetes i would probably recommend the combination of argo workflows for pipelines argo events for events argo cd for the github's part and i would probably add prometheus over there to have some metrics and maybe clear or something similar for security scanning and a few other tools the problem is that combining all those tools together is difficult it requires a lot of time and the end result is not something you can just give to everybody in your company and say hey there you go write your pipelines in argo workflows format and figure out events and combine it all with argo cd you need to spend a lot of time to figure out how those work how to combine them together and you would need to spend even more time building a platform of sorts that you can say hey there you go use it this is the combination that makes a lot of sense the combination itself does make a lot of sense but it requires a lot of work from sres or devops whatever you're calling yourself today or whichever role you're having until all that combined is working in a way that you can just give it to others and say hey now we have a system for continuous integration delivery git dubs you know everything you need for your applications from beginning until the end and the end is in production really with all that experience behind me i set to review dev throw and initially i was skeptical hey this is yet another cicd tool that does random things and [Music] it's nothing really special until i dig deeper into it and saw the potential and i must stress the word potential you will see later why that word is so important [Music] depth combines all those tools and a few others together in a meaningful package that is what would be the word very easy to consume it has its downsides it has its upsides but let's postpone the conversation for letter for now let's take a look at dev drone and see what we'll get the installation is relatively easy and straightforward all we have to do is execute help install or have upgrade and then wait for a while until the solution is up and running actually when you say wait for a while that is an understatement it will take approximately 20 minutes give or take until everything is up and running whether that's too short or too long we are yet to see because it really depends what we'll get so let me fast forward to the end of the process so that we see what's in that package is it worthwhile 20 minutes of your life okay let's see whether it's finished and we should be able to deduce that by the output of the command that i left running in the background if it says applied then yes it says applied so depth run is up and running or at least it should be up and running let's see what is included in that package if you look at the namespaces there is argon namespace which is the default namespace for argo workflows and that seems to be everything else is devtron something something let's see what's inside devtron cd there are many things over there let's see what did we get like app sync i'm not sure what that is there's argo rollouts excellent that's a really good choice for progressive delivery or deployment or whatever we are calling it today canary deployments for example anyways there is argo rollouts then we have argo cd which is for github's type of synchronization between git and whatever is in the cluster there is clear for security scanning good choice there's some dashboard probably daptron itself then we go to jafana i'm not sure whether we can access grafana we'll we'll see that in a second external secrets that's what i would choose as well or maybe not doesn't matter it's a good choice if not the best menial for storage again great solution nuts for events again excellent git sensor guard inception i'm not sure what that is cube watch lens that's a strange choice why would i need lens if i'm going to see everything through that from dashboard anyways we'll check it out later and we also got a few others anyways the point is that depth from packaged very good choices into a platform of sorts and we are yet to see whether they work well together but so far so good half of those would be my favorites if not more now we need to figure out the ip through which death throne is accessible and to do that i will execute uh simple or maybe not so simple anyways credit it will get me the ip of the service through devtron ui is accessible and now we can open it in browsers so let's see what we're getting a default user is admin that was to expected we need password i do not know what the password is but i can create the secret that contains the password so let me do that quickly it is curious that the secret comes from margot cd server but there is a relation between the two so i will give it the slack okay i'm logging in let's see what's going on at the beginning we need to go through some basic setup i wish i could have specified those values when executing helm installer and upgrade i checked they are not available as the values of the chart so we need to specify them manually but i guess for the users who like web eyes that's quite okay or welcome even right so the first one would be host ui i'm going to use the piyo to simulate the real domain i mean i could continue using the aptron with the ip but hey why not specify the domain however since i do not have a real domain i will use nepayo i will just copy the ip add deftron as the prefix and nip.io as a suffix and there you go you have a simulation of a domain next we need to configure githubs we do not know yet what it is but let's see what the settings are and it is straightforward we need to select between github or git club or azure suspiciously there is no big bucket which just proves my theory that bitbucket is dying slowly and a terrible debt anyways let me go back i can type git host github organization name and the username and the token and now be careful because i already suffered through this you need to use github organization you cannot use deftron with your personal account it needs to be an organization at least if you're using github so do not even try using it with your personal account without having any github organization that will fail i tried that i spent an hour trying to figure out why it's failing because the button save said everything is okay it wasn't so make sure that you're using an organization if you're using github finally the last step is to specify docker registry and at this moment i'm dissatisfied i really don't like when people call it docker registry it is not docker registry it is container registry because it is not only about docker it is not only about docker hub you can use almost any other container registry like kcr or bcr or whatever you might be using anyways let me go through those options first there we go save we are finished with the basic configuration we might come back to this page later to fine-tune it but for now we are ready to go now the start of that drone the main feature of devtron is all around applications and we are going to explore them in a few minutes for now i want to take it easy and go through the easier option or the faster option which is charts and you're now probably thinking hey every single kubernetes dashboard can deploy helm charts what's special about it well you will see in a second what's special because there is something very special and if you paid attention to the tools you probably do know what's special if you don't continue watching and you'll see so i can select among a few charts i mean there is more than a few i can extend the number of charts i'm using by adding additional registries but for this demo those that are baked in should be enough so let me select something what should i go for let's say in nginx just as a demo right nothing special so there is a description chart version and a few other things nothing special so far so let me click the deploy button and see what we'll get there i can type the application name and the project project is specific to devtron we'll see it later or not it's not really very exciting the environment where we want to deploy which is misleading environment is really in a space i don't like when products change the name of something that is already named anyways let me select the environment slash namespace and what else do we have here the rest are typical settings you know like chart version and the values file i can modify that values file i will change the number of replicas to three for example as i said before almost every kubernetes dashboard can do those things so this is nothing special so far and if you're curious whether there will be anything special you'll see let me deploy this chart and then you will see what makes this special now it is progressing it is deploying the chart blah blah blah all standard things that you can see in every other tool now let me take a quick look whether the pots are really running and yes the pots are there so the chart was deployed again this is pretty standard stuff however there is something that is not obvious by using deftron at least from the ui and we can discover that something by listing all the applications and if you're familiar with argo cd you know what's coming applications are argo cd resources that tell it where is the git repository and what is the path and what's or not that tells argo city the location of the manifest and let's take a look yes there is an application and this is what makes devtron special at least when compared with typical kubernetes dashboards instead of applying the chart directly inside of the cluster it created an argo cd application i will explain soon why that is important but for now let me retrieve the application and see the yaml representation of that application i want to check something and there we go there is a repo url pointing to repository that i never created and a specific part inside of that repository so let me take a look at that repo and see what's inside it and there we are if you go to the path directory we can see that there is a hem chart with all the information about the application now this is very important this is how github's works so let me explain the process in a nutshell of what really happened when we told daptron that we want to chart it did not apply the chart to the kubernetes cluster as most of the other tools would do instead it created the new git repository and then it created an argo cd application and then it told argo cd through that application to observe that repository and specific path in that repository and deploy whatever is defined there from now on we know exactly what we have in the cluster we know the desired state of that specific application because it is in kit and argo cd is doing synchronization so this is opposite from how we are traditionally used to deploy applications instead of a push method we have a pull method argo cd is pulling information from a git repository in depth run is making sure that the application are go see the application is created that's a one-time deal and from there on all the changes to that application are applied by changing the manifests in that git repository instead of applying them directly to your cluster so we have the desired state defining it and we have gargo city that makes sure that the actual state which is our cluster is the same as the desired state it is easy logical and yet brilliant because almost nobody is doing this at least not within the category of similar tools like you know ci cd pipelines and so on and so forth and if we go back to the depth run ui we can see some sort of kubernetes dashboard where we see the deployments replica sets pods and all the additional information we might need related to that chart the chart that was just deployed to the cluster through the manifest stored in it and that trend itself made sure that the repository exists and the charts are pushed there and so on and so forth now before we proceed and get to the main star of deftron which is applications let me go back to settings and see whether there is anything else interesting over there there are projects which is a way how to organize different applications and group them in a way i think it's a bit strange because we normally do that through namespaces and as you will see later that run also understands the namespaces anyways if you need projects whatever the projects are you have it in depth room i will move on to the next interesting thing and that is the setup of clusters and environments i have only one cluster so i will skip the clusters part you just need to trust me that you can manage applications in more than one cluster with devtron and we are going to move into environments because environments is what i'm interested in right now so what should i do let's say this i have two environments i have staging and production so i will create one i will create staging a few settings nothing really special and then i will create production again it's only about filling in a few fields and then clicking that save button that's it it's easy nothing really special i just wanted to make sure that i have two environments staging and production so that i can see how deftron works in multi environments and whether it can help me do what i want to do and what i want to do is to build and test and do all the things i do with applications some people call it ci i think that's misleading but anyways i want to build and run some tests and what's or not and then deploy to staging and then deploy to production let's see whether devtron can help me with that essentially it's going to be build deployed to staging and then deploy to production there are other settings we can use to fine tune what deftron does i've skipped through them partly because they are boring and more importantly because i'm impatient i want to see applications in action but before i do that i will delete the nginx chart simply because i have no need for nginx in this context i wanted to deploy the chart only to show you how you can do that so let's create a new application what do we have here at the beginning it's very basic i will type the name of the application select the project and choose the template actually i will use the blank template because i was too lazy to create templates you should just know that you can have templates that will simplify reproduction of the same patterns over and over again but for now blank templates should do and now we need to go through a bunch of settings it might sound overwhelming but it's relatively easy intuitive or partly intuitive we'll see whether it's intuitive for now let's see which settings do we have and the first in line is git material now why do you call it git material is beyond my understanding but hey it's a way to specify the repository where your application is that's what git material is essentially we need to specify git repo url and click the save button and see what's waiting behind the corner what's the next thing that i need to specify and that next thing is docker build config i can specify the registry i will use docker hub because it's most convenient it's not the best option but it is the most convenient one and in that context docker repository which again it's not docker repository because docker hub is only one of the repositories anyways the repository is my user you use your user do not use my user slash the name of the application and since the repository with my application already has docker file i can just click the save configuration button and then next and now we have a deployment template which is a way to say this is him values file without calling it hand values anyways depth from will create a hem chart for me and all i have to do to fine tune how my application behaves is modify a couple of things and in my specific case the only thing i need to change are ports the application in question is listening on the port 80s so we'll change 8080 to 80 and take a look whether there is anything else interesting for me to play with so what else can i change there's a bunch of things over there i'm not going to details of everything you can use to fine-tune your applications but choose one english yes english is a good choice because i would probably like my application to be accessible through a custom domain but since i don't have a custom domain i will use nepaio and to construct the new biodomain i will need the ip and i do not know what is the ip or whether daptronema has ingress installed i will just assume that it does have ingress installed or that it will install ingress since it packages basically everything i might need for delivering applications i assume it has some sort of ingress and i will guess that that ingress is accessible through the same ip as the after itself so i will use that to construct the host if it doesn't work they'll figure it out later next we need to create a workflow workflow is essentially a pipeline that in case of depth drone is split between ci and cd if you ask me there is no ci ncd cd is a super set of ci anyways we can create a workflow and the first part of the workflow is ci we can choose continuous integration or we can link an existing pipeline or we can use an incoming web hook i will go with the first option and choose continuous integration and since this is a simple repository with only the main branch and i would click the create pipeline button and see what else do i need to do to make this work now this is a nice representation says akira git repository i have a ci pipeline let me see what's inside of that ci pipeline we can execute it automatically or manually automatically means whenever we make a change to git repository manual would mean hey when we click a button i do not want to click buttons whenever i want to release something so automatic is the choice what it does essentially is build a container image and push that image to a container registry but there is an option to extend what it does by default by creating pre-built or post build stages and what we put in those stages is whatever we would like to have and the good thing is that it is extremely easy we just need to specify the command that we want to run in each of those stages and i will just echo something because i'm too lazy to figure out what i want to do for this demo so there will be an echo in the pre-built stage and an echo in the post build stage but you should do something more serious like before you build an image you should probably run some unit tests and you might want to do something serious after you build an image but in my case it will be the easy option just an echo message and we move on to the next stage actually wait a moment there is a big problem here potential big problem because yes i can execute any command i want but there is no option at least not easily visible and accessible to let me specify container image that should be used to run those commands because hey if i want to run unit tests i would like to run those unit tests in an image that has junit or gold testing or whatever you're using or maybe i would like to run some performance tests with j meter what's or not i'm really missing the option here to specify a container inside of which the commands will be executed maybe that's available somehow somewhere but it is not obvious how i would do that i'm not even sure at this point what will be the container inside of which those commands will be executed but i promise to myself i will try to be positive and this is a major drawback it is probably reflection that i did not yet spend sufficient time with devtron or not anyways let's move on to the next subject and see what else is waiting for us and now we can extend the pipeline by clicking that plus sign which will give us the option to deploy the application which in case of the eptron is called cd even though actually the whole pipeline is continuously but hey doesn't matter let's see what cd is and cd is extremely easy we just need to specify the environment where we want to deploy stuff which as we already noticed is essentially a namespace and to choose the deployment strategy and this is interesting or at least potentially interesting for staging i will go with the easy one rolling updates because i do not need more in staging but later on when we get to production i would really like to see how canary deployments work we can also enable security scanning but since i would be embarrassed for you to see how insecure this cv application is i will skip that option you should just remember that you can and that you should run security scanning of everything you do and that is very easy with the depth run you just need to select the checkbox and there you go now let me go back to the cd pipeline and see whether there is something else that we can do with it and just as ci has pre-built and post-build stages we have pre-deployment and post-deployment stages and that could be very useful i might want to do some things before the deployment happens and i definitely want to do some things after the deployment i might want to run functional tests or whichever other types of tests i have that depend on the application being up and running which is essentially everything except unit tests now this is inconsistent pre and post stages in the ci pipeline are a field where we can type any command we want to execute but in case of deployment the format is completely different i have something called config and then a sample script i do not understand why a sample of a config is a script but that's not that important what does matter is that this is something completely different than in the other pipeline and i cannot comprehend why is it inconsistent i would expect those things to be the same or follow the same logic and there is no clear explanation in the ui and i checked the docs there is no clear explanation in the talks either of what that is and what are the available options and why this is different and what is the benefit of one format compared to the other you probably noticed i do not like tools that are not consistent throughout the whole life cycle of whatever they're managing anyways for simplicity reasons i will skip the pre and pause stages for the deployment you should just remember that you can run things before something is deployed and after something is deployed now we're getting to the finish line i would like my application to be deployed to production after it was deployed to staging and after all the tests you know those that i would normally specify in the post-stage past so in my head it's a single flow that starts with building something and running some uri tests and then deploying it to staging and then running more tests and then if those tests pass deploying it to production which might have manual confirmation that yes i do want to deploy to production or it might be automatically depending on how much it trusts the tests executed after it was deployed to production so i will select production is the environment and specific canary is the deployment strategy canary makes no sense outside of production but in production canada is probably the best strategy to deploy something to production as long as it is done right and we are yet to discover whether this is done right or no for now i will just outline what i mean by done right canary would mean that we deploy a new release and redirect only portion small portion of the traffic to that new release and then we monitor metrics in let's say prometheus and if everything goes right then we increase the traffic going to new release to 20 30 continuously monitoring the metrics and making sure that everything works fine and eventually if none of the thresholds were reached we would get 100 and then our new release would be fully up and running and the old release would be shut down so country deployments are all about gradually increasing the reach of the new release and making sure that everything is working as expected before increasing the reach by creating metrics somewhere wherever the summary is i can only assume that that's what devtron does so let's move on to the next stage actually there is a settings button so let me see what it shows what is the canary deployments in depth run actually by default this is silly it's just sets the weight of the new release of 25 and then it waits for a while and then it increases the percentage until it reaches 100 that's completely pointless there is no point in baiting for a while and then increasing the weight if you're not measuring whether it's successful or not if you're not running tests or querying metrics or whatever you need to do so i need more and i'm not sure how to get more i can edit that field but i do not know what to put there i should probably consult the documentation let me see what's in documentation how can i connect it to metrics in prometheus and what are the available fields okay this is silly this is what we have max search max unavailable set weight and duration there is nothing obvious in this documentation that would help me deduce how i can tell deftron when to move forward and when to roll back what is success what is a failure how do i connect to metrics how do i run tests or whatever i should do with calorie deployment secondary deployments and like this are useless and i would not be this harsh if i would not know that devtron did not invent its own way of doing hundred deployments which is a correct thing to do that thrown is using cargo rollout in argo rollouts is a brilliant tool that allows me to do exactly what i want to do except that there is no mention that the afternoon is using argo rollouts it is hidden which we will discuss later and there is no mention how i can do what i want to do in documentation so if i would not know that argo rollouts is involved i would not know that i can actually do what i want to do but deftron is hiding it from me so i will ignore the fact that i know argo rollas from before and conclude that judging by the documentation i cannot do what i want to do and this way to employ country releases is just silly now another troubling thing is that i cannot deploy to production after i deploy to staging i can only deploy to one environment or two environments or three environments in parallel after the ci part and that's not what i want to do i do not want to go to production at the same time as going to staging i want to go to production after i go to staging and the problem is potential lack of flexibility if i would like to do what i want to do i would need to have different branches in different pipelines or workflows or whatever it's called here and then i would define ci and deployment to staging whenever i push to the staging branch and i would have another round of ci in deployment to production whenever i merge from staging to production and that might fit some people but it doesn't fit me in this case it sounds silly that i cannot chain different deployments one after another and that they all must go after the ci part but hey happy thoughts let's continue so far theftron looks amazing there are just a few things that should be polished let's say i am very harsh from devtron because i think that this is the tool that has a lot of potential and it just needs a couple of additional pushes to make it absolutely amazing so this is for your own sake the afternoon i'm scolding you because i know that you can be better okay this is the moment of truth we have everything set up it might not be 100 of what i want to do but nevertheless it is very promising and now we can test it out we can see whether it really works as expected and we will do that by making a silly change to let's say readme and then committing and pushing those files to a git repository and from there on devtron should do everything else right from now on i as a developer should be writing code and maybe running some local tests and whatsoever and then pushing changes to get and forgetting everything else everything else is fully automated except deployment to production which i set to manual so let me go to build history and see what's going on and we can see that the ci pipeline is running but it was executed slightly differently than what you might be used to unlike jenkins or circle ci or whichever other pipeline tool you might be using levtron did not create a web hook that is not defying daptron whenever i push changes to a git repository instead it is pulling for changes which has a downside the ci pipeline might not run immediately after i push something to git because that depends on the pull frequency however there is an upside i can lock my cluster so that nothing can access it including web hooks from gear because everything is happening inside of the cluster cluster might go out to get information like hey did you change a git repository but nothing is coming in it can be fully locked and that can make your cluster more secure essentially deftron is using the same logic for pipeline as the logic employed by argo cd or flux in similar github's tools it is pulling for information instead of waiting for push notifications we can see in the logs what's going on i will fast forward to the end of the process because frankly speaking this is boring now that the cia pipeline was finished we can go to the deployment history and see what's happening in staging in my case it is progressing but it shouldn't take long so let me jump to the terminal and see what is deployed what is running in the stage in airspace and we got the pod and the service and the replica set which created the port and we got the ingress because enabled ingress in the settings when i was defining the application itself so let me copy the host from the english and open it in browser and see whether my application is really working and it is performing and doing whatever the application should be doing and no we are getting deftron instead of my application and i think i know what the problem is i use the same ips the deftron thinking that that run might be accessible through some form of ingress but it is not it is exposed as an old port service english is probably not there let me double check whether there is english print installed it would be strange if there isn't because theft packs everything i could imagine now that needs so english is one of those things it must be there let's just see where it is and i can do that by listing all the services in all the namespaces if there is ingress there must be a service and if there is a service then it should be load balancer or not port as a minimum so that it is accessible from outside and then english takes over but no there isn't either ingress is not installed or it is not installed by default or it is hidden somewhere anyways i will install ingress myself and then change the address of my application and that should work there we are that's the ip i will copy the type and then i will go to the application settings and change the host of the application to be that ipv with the super snap bios so that i have a simulation of a domain actually it is a domain but not mine now it should hopefully work i'm still disappointed that the ingress is not packaged with depth or that it is not obvious how to use it nevertheless i will make another silly change to the application push that change to git repository and that should result in another ci pipeline running and after that ci pipeline the deployment should be executed and my application should hopefully be up and running with the new domain and there we are to see a pipeline was executed my application was built and after that the deployment started to argo cd and they should have the new release of my application up and running and that new release has new host address and i should be able to access it so let me retrieve all the resources including ingress from the staging namespace copy the address and open it in browser and see whether my application is finally accessible and there we are big success the application is up and running it is accessible we had a few hiccups down the road but devtron did it at least until staging let's see what's happening with production now in production we have a potential problem and that problem is that there is no way to specify differences between an application running in let's say staging and production in this specific case i would want my application running in production to be accessible through different hosts because staging and production are different they should have different hosts but there is no obvious way for me to find out how to do that i would probably need to split it into branches and create two applications instead of one application with different variations or something like that so we'll go there and initiate deployment to production which should result in depth from pushing changes to the git repository of the application and then aggro cd picking up those changes and applying them to the cluster and then argo rollouts doing country releases now the nice thing about manual deployment to an environment when we choose to manually deploy somewhere is that devtron shows us the list of all the images and we can choose which specific release we want to deploy to an environment vendor choices to do it manually that's really nice i like that part however the deployment failed there is something wrong and this is another potential problem with depron there is no easy way to figure out what's wrong when something goes wrong at least not through the ui i would need to go to the terminal and then go through the resources but since that run is effectively hiding which tools it is using it is not obvious unless you dig through it that it is using argo rollout so i might want to check the logs of argo rollers to see what's wrong or maybe something happened with argo cd and i would need to go to the locks of argos cd i could theoretically use the web ui of argo cd but it was not created it was not exposed through deftron because again that turn is hiding the tools it is using so given enough time and not sufficient help from depth run itself i could probably figure out what is wrong with deployment to production i will skip that part because i think i know what's wrong probably ingress is complaining that it does not want to deploy two applications with exactly the same hosts or it could be something else i will not worry about you watching me trying to debug what the problem is what is important here is that run is not really providing sufficient theme for you to find out what's wrong when something is wrong or at least that info is not easily accessible it is not clear where that information is within the adaptron ui so let me stop the demo view so enough there is much more to see about depth from but i do not want to make this video last for hours so let me stop the hands-on demo here and let's discuss devtron should you use it is it any good let's start with positive things with pros of devtron and there are many i will not name them all but only those that really really really really matter veteran uses the same tools i would choose to use if i would be making products like that it leverages the power of argo cd of argo workflows in argo roll outs it has clear inside it has graffana it has quite a few other tools and packages all those tools into something that is very enjoyable to use very easy relatively intuitive and so on and so forth i love how user-friendly daptron is the process it is enforcing is correct it is doing cicd type of pipelines it is leveraging github city storing all the information in it instead of manipulating clusters at runtime and that's absolutely excellent the process behind deftron is the process that i believe we should be adopting more or less but it has negative size as well to begin with it is hiding the tools that it is using which i think is a huge mistake because the tools that it is using and wrapping around and building on top of are absolutely amazing argo cd workflows rollouts clear and other tools should not be hidden from you argo cd for example has an excellent ui that is completely hidden from daptron users and hiding things is good there is nothing wrong in hiding things if you think that you can replace those things with something better so your def turn would give me equally good or better ui to see the resources deployed just as argo cd is allowing me to see the resources between the three and what's or not i would not mind swapping argo cd ui for depth run but deftron is not giving me that even though it is hiding the good parts of argo cd as for the pipelines part i think that i do not have a special need to see argo workflows ui so i'm really missing the ui of argo cd because it's absolutely awesome and uh daptron is not even trying to replace it another potential issue and probably the big one for me is the way devtron organizes the repositories with the manifest and everything it assumes that all the manifest for all the environments of an application should be in the repository of an application and i think that that is a mistake i prefer much more the model in which i have a repository of an application with the manifest of that application then separate repository for an environment that would have argo cd applications with all the links to the base manifest and then i could modify slightly how an application behaves in production compared to staging or other environments and if you're familiar with argo cd you would know that that model is called top of apps or application set depending on which resource you're using so i'm really missing the argo cd model called application set of application of applications i would really like to see depth from splitting those into different repositories one for each environment and one for each application and then environment repositories would contain application manifest that linked to the base manifests in the repositories of each of the applications and in that way i would have a clear view of what is running in production what is running is staging or whichever other environment i would have an easy way to customize my application running in production without repeating myself and so on and so forth the way devtron organized the applications managed by argo cd is not ideal it's not even very good and the last problem i have with devtron is that it is not doing the same things with itself as what it is telling you to do with your application if the definitions of your application should be in repositories why aren't there definitions of doctrine itself in the repository why isn't deftron itself managed using github's principles why isn't that good enough for depth run but it is good enough for your applications so i would like deftron to apply the same principles for itself and it is trying to convince you to use for your applications and those principles are good i would just like to see them employed on different itself now besides those negative things deaf turn is amazing i love the direction of the tool i might not be convinced that it is hundred percent where it should be but the direction is absolutely amazing and if the team continues down the path it is going right now and if it polishes the product and adds a bit more flexibility adds better integration with argo cd and other tools makes them more visible and makes them more flexible it will be a great choice actually it is a great choice right now you should try deftron right away it's just the time maybe too demanding i might expect from the tools too much so you might want to ignore me altogether try depron and let me know what you think let me know in the comments whether you like it whether you don't and so on and so forth

Channel: DevOps Toolkit

Views: 13,891

Keywords: devtron, devtron kubernetes, ci, cd, gitops, ci kubernetes, cd kubernetes, gitops kubernetes, k8s, kubernetes dashboard, argo cd, argocd, argo workflows, argo pipelines, argo rollouts, clair, devtron install, kubernetes cd, ci cd kubernetes, ci cd kubernetes deployment, ci cd kubernetes helm, kubernetes ci cd pipeline, kubernetes ci cd, devops, devops toolkit, review, tutorial, viktor farcic

Id: ZKcfZC-zSMM

Length: 39min 24sec (2364 seconds)

Published: Mon Aug 23 2021

Reddit Comments

[u/Kluelesskumari]

this is uber cool stuff. makes life so much easier.