Them: "Automated builds and deployments are a waste of time, they do strange things you didn't tell them to and they make mistakes"

Everyone else: \/

  • 5
    That's some heavy ignorance! The whole point, is creating the instructions beforehand, so you don't have to do it every time.

    So if your automation fails, you failed. If your automated deployment failed, you failed.

    Is that seriously not how people think?
  • 7
    Asshole driven development
  • 0
    Just compile all files manually one by one then
  • 2
    Right, the automated build makes mistakes. As opposed to the person who scripted it. Got it.
  • 0
    Ah. I come from a workplace were our builds are incredibly convoluted, to the point where they break regularly and pretty much no one knows how to fix any of it.

    So, I dont agree with the point being made, but I can at least sympathise with wanting to keep things simple enough that you could just whip up your own script to build and deploy anytime from memory
  • 0
    @illusion466 Please do elaborate on how your apparently undocumented scripts are failing, because of being incredibly convoluted. Because I've still to come across some instructions that have written themselves without being documented.

    Why are you guys using automation in such a scale, without being able to understand what's going on? From my perspective, reading the documentation and understanding the human-written scripts, would solve your problems regarding not being able to fix those scripts.

    I get that complexity is a thing, that's why you'd document everything and make sure humans understand the scripts.
  • 1
    @Kandelborg i wish I knew enough about our builds to answer those questions xD

    The code base is a large microservice ecosystem with significant coupling between services.

    We have a requirement that the builds have to configure the code for numerous environments, local, dev, test, prod1, prod2 etc.

    But this was set up so poorly, the names of these environments have bled into the actual production code. God knows why, but this is what I was given.

    We have a whole seperate application in the repo called BuildConfigGenerator, that walks the code base and grabs all the app.config files, and updates the xml from the default local settings to what ever environment we're building for. This must be built first.
  • 1
    @Kandelborg Some of these settings contain sensative data, like prod database passwords and api keys for web endpoints. To keep these out of the main repo, we have a "secure" repo where this data is stored. BuildConfigGen will grab those settings from that other repo when the build is being run from teamcity. Us devs cant see those settings. So if you misconfigured the environment, good luck working that one out.

    None of the services have a seperate build cycles. Its all coupled to the one build process. And since theres so much to build and deploy, builds take an hour and a half.

    Tests run during the build. Hooray for that.

    Its a shame all the tests rely on localdb in order to run, so you need to configure the build server with localdb, or you cant run tests. And you need access to write to the disk to use localdb, so theres that too.
  • 1
    @Kandelborg I cant even find the deployment scripts in the repo, so I assume theyre kept in the "secure" repo also. So I actually have 0 idea how teamcity pushes the artifacts to azure. 😥 Nor do I have direct access to the prod environment, so i couldnt rewrite my own if I tried

    And this is all ignoring the usual steps of restore dependencies, actually building the csprojs.

    I wish, we had a build script. But we dont. We have a build ecosystem, which you can only see half of.

    And no, theres no docs. You read the code for everything around here. Want to make changes? Read the code first, or talk to someone else whose worked there first.
  • 1
    @Kandelborg Tbh, I dont really care much for docs, so I think that's the least of our problems. But we do need to break down this build process into something more transparent. Should be able to release services in isolation, but we can't.

    But to fix it will take a lot of time, and the business doesn't want to pay for it. So they'll take the cost of slow builds and wasted developer time fixing transient errors because a unit test couldn't connect to a database or what ever.
  • 0
    @illusion466 I just feel bad for you then. If your business ever decides to try fixing it - I might be up for the task.. And quite cheaply. I need the money and have no problems signing a weirdly extreme NDA if needed.

    It sounds like hell, created by people who should have cared more but didn't get paid enough to do so.

    Oh well, docs are maybe for newbs but i enjoy writing them - I see legit reasons to just read source code, which I also do myself most of the time.
Your Job Suck?
Get a Better Job
Add Comment