Calling Developers!
We are reenergizing our code contribution process! Learn More

What are the Slack Archives?

It’s a history of our time together in the Slack Community! There’s a ton of knowledge in here, so feel free to search through the archives for a possible answer to your question.

Because this space is not active, you won’t be able to create a new post or comment here. If you have a question or want to start a discussion about something, head over to our categories and pick one to post in! You can always refer back to a post from Slack Archives if needed; just copy the link to use it as a reference..

Hi there, we're thinking about our development workflow at the moment and I just wanted to know, how

Options
U018XELUZS9
U018XELUZS9 Posts: 167 🧑🏻‍🚀 - Cadet

Hi there, we're thinking about our development workflow at the moment and I just wanted to know, how you work.
• Is anyone of you using feature flags with Spryker?
• If yes, do you use an external tool for that (like gitlab or split.io)?
• Do you have one single mainline branch (it's called main or master mostly) or do you use long-lived (older than a few days/weeks) feature-branches?
• Do you use branches for different environments (separate branches for staging/preproduction/testing or whatever)?
• Do you deploy automatically to production or do you have a manual step to trigger to deployment?

Comments

  • Alberto Reyer
    Alberto Reyer Lead Spryker Solution Architect / Technical Director Posts: 690 🪐 - Explorer
    Options

    We use feature flags in a lot of parts of Spryker, but only to activate/deactivate features (sometimes we have a configurable date to activate a feature from a certain time and decouple it from the time of deployment). We don’t use them for feature testing yet. All features are configured via the standard Spryker config, so we can enable/disable them per environment. We added another layer to configure feature flags via Helm so we can change them per environment without having the need to build a new container. Mostly we do this to be able to deactivate problematic features as quickly as possible.

    We use the master branch as production line and a development branch, which is the base for feature branches, which is deployed to a testing environment on every commit (automatically via Jenkins doing a docker build for all containers & ArgoCD to deploy all our docker containers to the related environment).
    For Staging we use releases/v..* branches, but staging & prod only will trigger a docker container build via Jenkins when there is a tag pushed of a certain format. Once this build is finished it’s automatically deployed to the related environment via ArgoCD.

    If you have more detailed questions, feel free to ask and I try to explain it as best as possible.

  • Alberto Reyer
    Alberto Reyer Lead Spryker Solution Architect / Technical Director Posts: 690 🪐 - Explorer
    Options

    (Context: We use Kubernetes and have one separate container per Application [ZED/GLUE/DB/Redis/RabbitMQ/Scheduler/etc])