I'm part of a small team that releases updates 3-4 times a day, thanks to tools like Cursor and Claude boosting our efficiency. However, I'm struggling to know which version of our payment service is currently active in production. To figure it out, I often have to dig through GitHub actions, cross-check ECR tags, or ask someone on Slack. We have multiple environments like staging, sandbox, and production, but sometimes a feature just sits in staging for weeks, leading to situations where we have to 'excavate' the latest updates when someone asks if the new checkout flow is live. Is it typical for small teams like ours to face this issue, or are there better solutions out there for tracking what's in production? We're not large enough to have a dedicated platform person, so I'm curious about effective workflows at our scale.
5 Answers
One method we use is to ensure that a story is only marked as done after it's actually deployed to production. After merging, an automatic comment is added to the issue when the deployment completes, giving everyone visibility on what’s live.
Have you considered implementing GitOps? If everything is in Git, you should have a clear source of truth about what's deployed in your environments. If it's not in there, it simply isn’t deployed!
That’s true! And using commit hashes or version tags can also help track what's currently running in production easily.
Sounds like your team could benefit from having a central database or a dedicated dashboard that records deployments and allows everyone to see what services are live. Start implementing these systems, and it'll be easier to keep tabs on everything in production.
Integrating automated tracking to monitor deployments could solve a lot of your issues. We utilize tools like JFrog Fly to automatically log what’s in production, eliminating the need for manual checks.
It sounds like you're missing some observability tools. Having a dashboard that displays the current versions running in production can make tracking much easier. It can significantly reduce the need for back-and-forth digging during deployment.
Yeah, the issue seems more about improving your observability and change management practices than anything else. It’s definitely a gap you can work on!
Different teams have different workflows; ours tracks when code is merged, but we hold off on releases until everything is tagged for deployment. Flexibility in when to push to production has worked well for us.