Comment by speed_spread | Hacker News Reader

Comment by speed_spread | Hacker News Reader

- CI servers could do much more and their findings should be merged back into the IDE UI: integration tests, CVE analysis, tracking possible merge conflicts from concurrent feature branches

- Bake the distributed nature of the software process into the IDE. What environments and servers is the developed software running on? That information is currently spread out over multiple tools and should be synthesized and presented coherently from the IDE, so one could dive straight from it's IDE into a problematic server and start debugging using the appropriate code without having to spend 2 hours reproducing the build configuration locally.

- Finally, _Team Workflow_ is especially taken for granted, ground rules being implicit in most organisation but having the most actual impact on team productivity. How long should a PR take? How is the software qualified for release? How should new git branches be named? Important, basic stuff that changes across teams and projects that should be formally documented to lower friction for newcomers and small-time contributors. This would turn perceived arbitrary "gatekeeping" into a rational, safe processes.

I have to say I really disagree with the thought that one should bake a whole bunch of custom functionality into their ide. My company did this. A special, custom version of eclipse was required to even build or deploy their applications. What happened? It was abandoned, and since that build / deploy functionality never existed as independent utilities it was completely lost. I had to piece together how to build my application by pulling build files off of our old ass legacy cicd server and even that process is pretty horribly broken. As things stand, the legacy app I'm tasked with keeping alive is held together with bailing wire and chewing gum and almost all requests for new features are turned down. This is not a unique problem to my team, it's org wide. Tons of legacy apps are limping along because 'the knowledge' of how to do things properly was bundled up into eclipse plugins we no longer have access to.

That's no different to requiring an arcane incantation of shell scripts that call maven, git, curl, docker, , etc. The advantage of having it built into IDEs or CI servers (and by built in I mean TeamCity/Jenkins providing it, not a self inflicted third party plugin) is that you can build around these steps. Imagine if all CI servers supported merge previews or mergebots - that workflow gets unlocked for everyone!

at least with the shell scripts I can quickly see what it does. I much prefer the unix philosophy of small bits of code that do one thing, and do it well. Such things can be combined to make bigger things. Want to make a plugin out of those individual scripts? Knock yourself out! Meanwhile, a decade from now, some engineer can actually reconstruct if needed. Much better than a 'binary blob' plugin that gets abandoned.

I used to do this, on and off, with vim. Hey customize this, and that, and add some special key bindings and plugins. Then you go to ssh somewhere and you're totally lost. Ya, I know there are ways to manage your config for vi but it's not perfect. I find it's sort of like keyboard layouts like Dvorak. Sure it might be more efficient, which is debatable, but there is a huge value in being able to sit down at just about any keyboard and knowing the layout.

At one point it takes longer to implement a simple feature then it takes to rewrite the whole program, that's when you rewrite the whole program (using a sane amount of dependencies - as few as possible)

I totally agree a specific IDE shouldn't be _required_ to operate the software platform. The IDE should ever remain a catalyst, accelerating a process that could be done by hand from the CLI whenever required. The good IDE should know about these different tools and present them in a a coherent manner. The I in IDE should mean more than integrating a compiler and debugger with a text editor.

addendum: the "team rules" being kind of novel, these should be encoded in a human-readable file, actionable from the CLI as well as the IDE. I've been pondering for a while how such a workflow tool could be like.

Just a addition to the _TeamWorkflow_ it would be great if there was a standardized Way to have a kan-ban pipeline mapped into the IDE. Like Icebox -> First Implementation -> Review -> etc -> Deploy & DevHops

I always found that "assign" to person of gitlab to be clunky and the use of CI/CD Piplines to map the concept even clunkier.

If every pipeline station becomes something abstract, and the people just check in with their station, in the IDE, with the IDE even pre-configured to the current Station (basically pipeline-modal) that would be real neat.

Some of us already have that, as IDE Presets, switching manually, but having that baked in, would be a benefit.

As someone on a team heavily reliant on CI, I think we really need better support for running things locally without CI, though having integration with the server for looking at results is great too.

For example, I want a workflow where I can click on a failing test from the CI and have it pull up the source code of the test in the IDE and run said test locally with a debugger.

There’s a lot of interesting thoughts here. Especially in points 2&3, around integration between dev and deployed environments and workflows being integrated into the tooling.

Our company Coherence(withcoherence.com) is pre-launch but is working on these exact problems if anyone is interested in helping to solve them!

So basically like Visual Studio Enterprise or RAD Studio Architect.

Reply on news.ycombinator.com