wing apps can be deployed by a `wing deploy -t <platform>` command

tsuf239 commented 8 months ago

Use Case

The deploy command compiles and deploys a wing project in a single command

Proposed Solution

No response

Implementation Notes

No response

Component

No response

Community Notes

Please vote by adding a 👍 reaction to the issue to help us prioritize.
If you are interested to work on this issue, please leave a comment.
If this issue is labeled needs-discussion, it means the spec has not been finalized yet. Please reach out on the #dev channel in the Wing Slack.

hasanaburayyan commented 8 months ago

Just a note,

My initial thoughts are that platforms should also define how they are deployed with the wing deploy command. So perhaps we just add this as another platform hook called deploy(app: App)

tsuf239 commented 8 months ago

Yes! and also preDeploy and postDeploy could be good, (to remove the awscdk related from the wing test command for example, I have an issue open for that)

Chriscbr commented 8 months ago

Adding a deploy CLI command increases the surface area of the CLI and the interface between the CLI and each platform provider implementation. I'd also anticipate a lot of users might want to customize wing deploy to ensure their environment is set up a certain way (like using certain cloud provider credentials), or running validation scripts, or customize the flags provided to terraform apply etc.

Is there a strong reason for adding this? I'm wondering if the value it adds to the user justifies the long term maintenance and support, especially if we are recommending users to deploy applications within CI/CD.

As a workaround, a user can create a bash script that runs wing compile and cd <folder> && terraform apply, and that will let them deploy in a single command while being infinitely customizable.

hasanaburayyan commented 8 months ago

Is there a strong reason for adding this?

@Chriscbr yea this is one of the requested features in the user story for use cases.

CLI command increases the surface area of the CLI and the interface between the CLI and each platform provider implementation.

I think if we pawn off the actual work of deploy to the platform then the long term maintenance of these deploy commands fall on the platform provider (of which we most are owned by the wing core 😁), which would be totally customizable by overriding the deploy logic with a custom platform. Which would mean the responsibility of the cli is to only call the deploy method that is extracted by the platform manager.

Personally I dont have a strong desire to see the feature, though I do imagine that its something that users would like to see over custom shell scripts or changing directories to deploy code, since it means that a user who just wants to use lets say tf-aws needs to be familiar with the deploy procedures of a platform, adding some friction to the process.

(I also dont have anything to back up the desire for the feature besides a hunch 😁)

Chriscbr commented 8 months ago

We already have are some open issues about DX problems related to running deployments on the user's behalf with wing test -t tf-aws (to be honest, I'm not sure how well this capability is holding water):

Some other questions:

How would wing deploy be experienced by first-time Wing users who have no background with AWS or Terraform? Today, terraform apply and cdk deploy and pulumi up all have different CLI output. Some show the resources you're deploying or updating, some show you progress while you're performing a deployment, some require you to approve the deployment, they all likely use terminology specific to that provisioning engine, etc. Could this be confusing?
There could be compatibility issues -- for example, what if the Terraform CLI has differences between versions, or if a user wants to use OpenTofu instead of Terraform? Would each Wing platform provider need to supply a list of range of terraform CLI versions or cdk CLI versions that it's compatible with? This may be additional complexity that we would have to maintain and update going forward.

tsuf239 commented 8 months ago

I'll start with the most straightforward and simple way and we'll build it from there- based on users' complains/constraints/bugs/issues

eladb commented 8 months ago

@markmcculloh you are the owner of the CLI, so I'll defer to you to make this call.

MarkMcCulloh commented 8 months ago

I wish we could take on the responsibility of a deploy command but yeah I agree with the concerns raised in this thread. I'd love to see this capability exposed on platforms someday in the future but I'm not convinced we should take it on right now.

In the short term, I wonder if we're just not providing enough help/information to the user. Unless you read the docs, it's not obvious where the deployment artifacts go and what to do with them.

Unlike sim compilation, users are expected to take responsibility for the next steps with the output themselves. We could output something in the CLI to convey this.

I'm not even sure if verbosity matters since compiling to a non-sim target should not be part of a dx hot-loop.

Not to blow up this comment too much, but this feels extremely related to a wing-based build/task system, which could include the ability for user's to define their own deploy command.

hasanaburayyan commented 8 months ago

I totally respect the decision to not take on the deploy command, I also stand by whatever you think is best @MarkMcCulloh

for my curiosity sake though I’m just not quite sure I understand the complexities that we’re discussing here. In my mind the platform providers know where the output artifacts go (unlike a first time wing user, who would need to understand a platforms deployment model) and there’s less complexity involved than the wing test command since it’s a single app deployment and no concerns around multiple isolated stacks.

If the user is missing a required cli or some incompatible version of some tool then the error could be bubbled up and the onus is on the user to resolve.

But yea maybe I’m missing something

MarkMcCulloh commented 8 months ago

Overall I think it's about which responsibilities we're exposing ourselves to. Once we have a wing deploy, we're telling users that wing itself is responsible for (and opinionated about) deployments. This exposes us to a new area of work, both as bugs and desired features/gaps.

As you're saying, I don't think implementing this itself is very difficult. Just worried about what comes after.

tsuf239 commented 8 months ago

Ok, We have to update the user story and the tutorial accordingly

eladb commented 8 months ago

Reopening. @MarkMcCulloh your call if this is something we want to keep open or close for now.

staycoolcall911 commented 8 months ago

We decided not to do it. Closing.

staycoolcall911 commented 8 months ago

Reopening per feedback from @eladb - we'll leave this open and see if we get feedback from the community. Changing to p3 for now

JensRoland commented 2 weeks ago

This feature seems to be the epitome of the "batteries included" philosophy. Not including it would be hanging a lot of non-expert users out to dry.

Just don't try to boil the ocean. Start with the simplest possible solution -- calling the IaC tool with default parameters -- and then provide a config property for developers to insert a custom deploy command.

eladb commented 1 week ago

I agree with you and we are opening to taking a contribution to add this feature. Would you be interested in working on this?

hasanaburayyan commented 1 week ago

As far as implementation is concerned I think this could work similar to how wing secrets was implemented. Assuming its still the same, been a while since Ive been under the hood 😁

winglang / wing