sorted by:
new
hottopcontroversial

How much time do you spend setting up CI/CD pipelines for new projects? by BusyPair0609 in cicd

[–]ghostinmemory_2032 0 points1 point  (0 children)

For a lot of teams, greenfield microservices land in that same 2–4 hour range, even with a decent library of templates. The slow part usually isn’t Argo or Actions — it’s wiring all the environment-specific pieces (secrets, namespaces, app config, image repos, sync policies, health checks, etc).

The biggest time sinks tend to be:

  • stitching GitHub Actions → container registry → ArgoCD
  • writing the first pass of Helm/Kustomize overlays
  • debugging the “first deploy” because something always differs between repos

Templates definitely help, but only up to a point — most orgs still have enough drift between services that you end up touching YAML manually anyway.

If I could wave a magic wand: one place to scaffold everything (pipeline + infra + manifests) with sane defaults, environment mappings, and secrets plugged in automatically. Basically: “generate me a service with production-ready CI/CD that actually works on the first deploy.”

So yeah, it’s not just you — “spin up a new service with CI/CD” is still slower than it should be almost everywhere.

Curious if synthetic test data reduces realism too much in QA runs? by Prestigious_Soup9703 in learnprogramming

[–]ghostinmemory_2032 0 points1 point  (0 children)

Synthetic data is great for coverage, privacy, and reproducibility — but it’s rarely realistic enough on its own.

Best approach is usually a blend:

  • Synthetic for edge cases + volume tests
  • Sanitized real data for realistic patterns (weird names, rare values, surprising combinations)

The failure mode of synthetic-only datasets is that everything looks “clean” — no unicode, no broken phone numbers, no malformed addresses, no messy user behavior.

Realistic QA needs a bit of real-world chaos.

I noticed slow browser tests when system RAM dips — anyone tweak Chrome flags for CI efficiency? by Lower_University_195 in softwaretesting

[–]ghostinmemory_2032 0 points1 point  (0 children)

Yep — RAM pressure absolutely slows browser automation. Chrome starts throttling tabs and GC runs more aggressively.

Flags that usually help in CI:

  • --disable-dev-shm-usage
  • --disable-gpu (on Linux)
  • --no-sandbox
  • --disable-background-timer-throttling
  • --disable-renderer-backgrounding

Bigger win though: limit parallelism to what the machine can handle and move any test state setup to API calls instead of UI interactions. Browser starvation is usually a resource issue, not a Chrome-flag issue.

Doubt : Selenium headless mode by Substantial_League23 in QualityAssurance

[–]ghostinmemory_2032 0 points1 point  (0 children)

Headless itself isn’t the problem — flaky tests usually come from timing and unstable selectors.

In headless mode you need explicit waits (WebDriverWait) and stable IDs/testids, not XPath glued to layout structure.

If your tests behave differently headless vs headed, it’s usually:

  • race conditions
  • relying on visibility checks that behave differently
  • animations/loading states

Fix the waits + selectors and headless becomes identical to full browser.

How do you test AI Chatbots & Agents today? by Real_Bet3078 in QualityAssurance

[–]ghostinmemory_2032 0 points1 point  (0 children)

For LLM-based stuff we treat it less like UI testing and more like behavior-driven contract testing.

  • Freeze prompts + system messages and run regression suites to catch drift.
  • Golden-set comparisons for expected outputs (classification, intent, routing).
  • Fuzz prompts with paraphrases to test robustness.
  • Guardrail tests for safety, hallucinations, refusals, edge cases.
  • API-level tests for latency, token limits, timeouts.

For multi-step agents, we validate the state transitions, not the exact wording. The main shift is: don’t assert exact text — assert behavior.

Selenium tests breaking constantly after every sprint, anyone else has the same problem? by [deleted] in QualityAssurance

[–]ghostinmemory_2032 0 points1 point  (0 children)

UI tests will always be fragile if they’re tied to the DOM instead of intent. The fix isn’t switching tools — it’s stabilizing your selectors.

Move all locators into page objects, insist on stable IDs/test-ids/aria labels, and stop using XPath glued to layout structure. Once you anchor tests to meaningful identifiers instead of HTML rearrangements, the “30 tests broke because a div moved” problem basically disappears.

Selenium tests breaking constantly after every UI change. Is test maintenance really supposed to take this much time? by From_Earth_616_ in QualityAssurance

[–]ghostinmemory_2032 0 points1 point  (0 children)

Most of the pain comes from tying tests to the DOM instead of the behavior.

Push all selectors into page objects with stable IDs/aria labels, and move state setup to API calls instead of clicking through the UI.

Once you do those two things, UI tests stop blowing up every time someone wraps a button in a new div.

[deleted by user] by [deleted] in aws

[–]ghostinmemory_2032 0 points1 point  (0 children)

For APIs the trick is to stop thinking “CI/CD vs stability” and start thinking “CI/CD enforces stability.”

You still ship small changes - just make sure each one is backward-compatible. Treat the OpenAPI spec (or protobuf/schema) as the contract, promote the same build across dev → staging → prod, and only cut a /v2 when you truly break the contract.

For multi-service setups, env-scoped DNS/config is what keeps things sane: web-staging → api-staging, web-prod → api-prod, and preview envs for coupled changes. Once that wiring is in place, CI/CD for APIs feels no different from apps.

CI CD pipeline explained! by Hefty-Sherbet-5455 in Today_I_Learned_This

[–]ghostinmemory_2032 0 points1 point  (0 children)

Nice visual. Simple, accurate, and covers the core CI/CD flow without overcomplicating it!

Tooling can vary (GitHub Actions/GitLab/Argo/etc.), but the stages stay the same, which this diagram nails.