Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
ltlian21884yBuilding the same thing for two different environments always felt like a "surely there's a better way" for me. All I want is to build the same app but use - eg. - different config files for the api client and maybe include a debug view for the test env.
It's not *hard* in the platforms I've used, we just can never land on a clean solution which doesn't take the job from "obvious at first glance" to needing an onboarding for new members to explain how it works.
We usually end up using separate but nearly identical jobs to keep it simple. The biggest caveat then is having to "just make sure" they are in sync, and again, without overcomplicating it.
Surely there's a better way. -
@ltlian By environment, you're referring to e.g. local vs staging vs. production environments (or however you have it set up) and having different builds for each?
-
ltlian21884yYeah. Test vs QA vs prod. Built and deployed in similar ways, only different in connection info for the frontend app
-
@ltlian Ah right, I've faced this exact issue. What build tools are you using? Are you using an infrastructure definition language of some sort (e.g. terraform) for the backend? Is the connection information stored somewhere otherwise?
-
From what I've seen in trying to find/build a good generator of Azure ARM templates using Powershell is that, the higher level and more user friendly you try to make something, the less flexible and powerful it is. For example, there's a module that can do it nicely but the user has to define the structure themselves and it doesn't validate if it's correct or not, but there's also a module that provides specific functions for each type of resource but not all resources are supported so it has limited usability.
-
ltlian21884y@junon Currently just azure pipelines using yaml definitions.
Like I mentioned there are definitely ways to achieve it. One approach we used in a different project was to have a condition in the pipeline which ran a script that echoed some runtime variables to a file which got built into the application.
It worked well enough, but it wasn't obvious unless you had it explained to you. The more we tried simplifying it the more complex it got, so we just went back to separate pipeline jobs.
Complain about your build systems/pipelines here please! I want to hear about it.
----
I'm finally ready to publicly say I've been designing a build system. It's a culmination of around a decade of studying, thought, ideas and prototypes.
If you have any sort of build step in your project (any language, any compiler) that is unusual, custom, weird, or has a lot of requirements, extensive, etc. - anything even slightly outside the box - please let me know about it below. I want to know as much as possible about it.
Any strong opinions, hateful comments, gripes or annoyances, etc. please don't hesitate. I'd love to hear what issues you face with build systems. I want to make sure such cases are covered.
I'll also answer any questions for the curious.
question
build systems