|
|
|
|
|
|
by dgruesso
2820 days ago
|
|
|
Thanks for the feedback Don. For your particular use case, you could use the same cluster for multiple environments if you have separate namespaces and use separate service accounts for each. Using RBAC will further ensure you don't have any collisions, this way if there's an error in development, the production namespace will remain untouched. When deciding which features are paid vs free we ask ourselves if the particular feature may be more relevant to larger organizations; that doesn't necessarily mean there won't be a use case at smaller companies, but just wanted to let you know our reasoning. You can read more about it here: https://about.gitlab.com/stewardship#what-features-are-paid-.... |
|
|
The environment specific variables are more frustrating for me because I would consider good environment isolation a necessity, rather than something that's subjectively better / worse depending on the size of an organization.
I think everyone driving deployment from CI should, at a minimum, start with two environments - 'dev' and 'prod'. The number of environments would have been a much better feature to tier IMO. I don't really need 'test' or 'staging'. To me, those extra environments seem more practical for a company that has a strategy for promoting deployments as a part of their QC policies.
CI in particular is an area where I think the the product tiers might be a mistake. The goal should be getting everyone into the mindset of "use GitLab and follow their opinion for CI and you can one-click deploy to and scale on X, Y, or Z". The promise of cheap, consistent deployment options with the ability to "throw money at it" to scale up is what makes sense for me. It's unlikely I'll ever have a product that gets popular enough that I need to use the scaling features, but that's what everyone dreams about so it's easy to capture the low end with the promise of low / no upfront costs and the ability to scale if you win the lotto.