Learn More
Resend Email
1
RageExpress
1y

So trunk-based is the new approach everyone is using, because it is so cool.
I used gitflow for the last projects with azure devops, set up the pipelines like tipically in 1 week if I had other things to do with the help of the portal clicking through things. PR-s triggered pipelines, everything worked cool.
But then trunk-based got momentum, so I worked with this client where 2 developers worked for !!!3 months!!! to setup trunk-based pipeline. It was not my money, so I did not say a thing. They were using infrastructure as code.
I am all in for automation, but seriously? Then again, another project where a DevOps team took 1 dev-month to setup the pipeline + meetings. And what do you get in the end? So that the same image goes on all environments? Like how many releases do you have for prod in a year. Lets say 24. 24 x 5 minutes of manual work for the release, that is 2 hours. So my question is why would you spend 2 hours of manual work while you can automate it merely in a month? Everyone loves to code, but using the ui on the DevOps portal saves you so much time. I don't get this. Maybe I am getting old :D

devrant

trunk-based
Favorite
Ranter
Comments
  • 0
    1y
    a week is kinda long IMHO.

    unless you count the endless meetings with clients to try and get the info you need.

    but once everything is gathered, setting up deployment for our projects is usually a matter of a few hours at most
  • 0
    1y
    @tosensei meetings was part of it, but mostly it was because I learnt how to do it along the way. But again. 1 week with gitflow and 1-3 month using trunk based, try to compare that.
  • 2
    1y
    I mean, this obviously depends on complexity of the project and yada yada. But in the end it boils down to more than just the time it takes to deploy a release. Developer experience, possibility of doing rollbacks, multi environment shit just to name a few. Also, infrastructure as code has many advantages over many manual deployment methods imo, such as ensuring consistency and handling being a bit more environment agnostic. But many months sounds like a lot of time to me assuming they're experienced DevOps engineers.
  • 0
    1y
    @ScriptCoded they were not experienced in either case imo. but for me the question seems to be why business is using a method that is newer but has no competencies in that takes longer to accomplish over something that is out of the box and fits the project just as fine. And the only justification always seems to be that the are trying to save manual work. But in these cases they spent 100x more time on automating stuff that the work itself would have been.
devRant © 2021 Hexical Labs LLC
Privacy Policy  |  Terms of Service
Add Comment