I least not lately. 10 years ago : absolutely. But nowadays it’s a docker command or a git pull then yarn/gradle/whatever … and if that does not work something is wrong and a ticket is raised.
Theres already a lotnof complexity in those "simple" parts
From personal experience, I used to use TFS for version control for a few years before using git at my newer job. I also never once had to deal with yarn or gradle.
And I also know from experience, that you can make a unmaintainable mess in every build system.
Also, who is gonna teach the juniors how to use the tools, if everyone sets that knowledge as mandatory? Or do you expect everyone to learn it in their free time before starting any tech job?
The step in those builds should works on developer machines. Is that too much to ask?
If the step in the build do not work? How did that get merged in the first place ?
Ideally, you would
> The step in those builds should works on developer machines. Is that too much to ask?
Quite often, yes. (Secrets that are only on the build server/shared database you cna't connect to without a barely working VPN and such)
> If the step in the build do not work? How did that get merged in the first place ?
Because there is no CI/CD pipeline to stop you?
There are tons of reasons why it can be extremely hard to get into a legacy project as a new person. And that's just setting it up. Ideally, this wouldn't be the case. But sadly, the real world sucks
Last time I worked without reproducible builds was 2005-ish ?
My experience : once someone in the C-suite vicinity enforce a lock-down, things fall in place rather quickly.
Ex : nothing get deploy manually. I don’t care if we miss the next prod push, we will catch the next one.
> the real world sucks
My work is as grounded in the real world as well. And I spend year contracting for bottom feeders company. Hard to do more real crap. At some point is valuable to define priorities.
> Because there is no CI/CD pipeline to stop you? There are tons of reasons why it can be extremely hard to get into a legacy project as a new person
Fine. But lack of validation should not be a reason. If no pipeline checks and no humans checks as well. Then you are deploying un-vetted software.
I assume familiarity with standards tools of the tech stack.
famous words.
It's eerie that I had this experience 5 minutes ago, in a stand-up onboarding meeting for a new colleague: they ran into issues when trying to launch the project through the IDE run configuration (IDE version, plugins, project configuration etc.) but the container based approach that I introduced just in case about a year ago just worked, the first time.
Provided, I actually went the extra mile and documented how to authenticate with the necessary private repos etc., so one could follow a short list of steps bit by bit.
> Lets you test your software in exactly the same environment as in production.
I'd say containers are good for this, but not perfect. Depending on what you're developing and how, you might still run into stupid issues: mostly in setups where you use Windows for your development box and bind mount files, the permissions will get screwed up, as will line endings.
Here's an example: https://blog.kronis.dev/everything%20is%20broken/containers-...
I'd say the best possible developer experience nowadays is along the lines of:
- have GNU/Linux distro X as your developer workstation
- have the same GNU/Linux distro X as the base for your containers (a more cut down version, but with same package repos)
- still ship software in containers, ideally run those on nodes that have some GNU/Linux distro
I can just install some software on the workstation and have it run basically the same as it will in the container, same install instructions and everything (though maybe less focus on clearing up package caches not to bloat container layers, which doesn't matter outside of those). Sometimes that is useful for local debugging or launching things directly with IDE integrations, as opposed to trying to get remote debugging working (though things like DBs, Keycloak, Redis etc. are still better in containers, I'm talking more about back end/front end tooling/runtimes).
If you go to this other post of mine, it actually has an example of this: https://blog.kronis.dev/articles/a-week-of-linux-instead-of-... (search for "Being able to run the same thing inside of containers and on the host system.")
At this point I'm basically unironically shipping my dev box, sans dotfiles. It doesn't scale, but it's the least painful dev and ops experience I've had in years. One can probably take elements from this for more sane and enterprise setups, too (such as focusing on GNU/Linux instead of Windows for development, or at least something with a similar file system).