Deploy only specific Stacks, StackTemplate and Units

[kinseii]

What would you like to add

I have a very big problem with how to deploy different parts of the infrastructure if there are several people working on the project. The thing is that using terragrunt we can deploy modules selectively, using the options --terragrunt-include-dir, --terragrunt-exclude-dir, --terragrunt-strict-include, etc. Or even by going into the desired module and deploying just that one. Cluster.dev doesn't allow you to do this yet, and as a result there will be problems over the fact that while one engineer is working on one StackTemplate or even a unit, another engineer will have to wait so as not to roll back his changes. In this case, I suggest implementing options specifying specific Stack, StackTemplate, and even Units.

[voatsap]

I think we can implement this in terraform style targets (https://developer.hashicorp.com/terraform/tutorials/state/resource-targeting)
So you can specify particular targets like
cdev apply --target="stackA.unitA, stackB.unitC, stackC
With this commands the reconciling would take place on targeted units and all required dependencies that those units may need.
Also additional option like ignore-target, ex
cdev apply --ignore-target="stackA.unitA, stackB.unitC, stackC

The dependency in graphs would be tricky, @kinseii do you need those targets respect dependencies or you also need an option that could force cdev to ignore any dependencies and just execute that particular unit?

[kinseii]

I think we can implement this in terraform style targets (https://developer.hashicorp.com/terraform/tutorials/state/resource-targeting) So you can specify particular targets like cdev apply --target="stackA.unitA, stackB.unitC, stackC With this commands the reconciling would take place on targeted units and all required dependencies that those units may need. Also additional option like ignore-target, ex cdev apply --ignore-target="stackA.unitA, stackB.unitC, stackC

Yes, that's exactly what I need, thank you!

The dependency in graphs would be tricky, @kinseii do you need those targets respect dependencies or you also need an option that could force cdev to ignore any dependencies and just execute that particular unit?

Yes, such an option to ignore dependencies is very much needed. For example, there may be some non-consistent changes in the code (someone has fixed something or work is in progress) that should be ignored.

Really appreciate the quick response, thanks a lot!

[voatsap]

We are working on that

[voatsap]

We have assessed the overall complexity of this feature and determined that it would require more resources than we can allocate at this time. Therefore, the only viable option to expedite this process is to pursue commercial support.

If your company is interested in this option, please reach out to us through the contact form available on our website: https://cluster.dev/.

We apologize that we are unable to release this feature currently, but we hope you understand our resource constraints.

Thank you for your understanding.

[kinseii]

Hi @voatsap!

thank you for the clarification. The implementation of your product was and is entirely my initiative, as I developed the initial architecture and IaC. We built it on terraform/terragrunt (tf/tg). However, we ran into the fact that in our configuration IaC over tf/tg is starting to get very complicated. I'm thinking proactively a couple years ahead and want to lay the foundation to make infrastructure management easier and your product can really help with that. Declarative description in yaml format lowers the entry threshold for engineers, and generating full terraform code with all inputs really makes development and debugging easier (which terragrunt doesn't provide). Provider parameter overrides are also a necessary option for us. All in all, I see a great future for the project with fast development.

Unfortunately, at the moment I am only an engineer and my role in decision making is minimal. My implementation strategy was to convince my manager to change the tool, for which I wrote a PoC to show the real advantages of cluster.dev, and then to present the product to the infrastructure team. And then, having agreed on all the nuances, we could start a smooth transition. The only significant blocker that my manager does not approve of is the extreme inconvenience of team work on one project. And all of our work is teamwork and all engineers are working on IaC at the same time. Any uncoordinated deploy with the team can lead to rollback of changes by colleagues, these are risks that neither I nor my manager are willing to take. Since our company is still in startup mode, we are unlikely to be able to carve out any budget at the moment to develop the features we need, especially since we already have IaC on tf/tg. For these reasons, we will have to give up on implementing cluster.dev.

However, I'm sure it will work out for you. Other engineers need more information about your product, more use cases, which can give valuable feedback. Thanks again for the product!