[DOCS] - Provide a proper Developer workflow scenario

[julianxhokaxhiu]

Write a documentation page with the ideal workflow for a developer.

How to write an application, which port is exposed by default, how to deploy a service, how to query the service (Where do I find the endpoint), how to pass environment variables and secrets.

[julianxhokaxhiu]

After working on this item for the past two weeks, here is my current status update:

• We kickstarted a Github Action project that will help developers pack their project as a container and deploy it immediately to a cluster prepared with this project. This action can be found here: https://github.com/nearform-actions/k8s-kurated-addons-action
• The action provides a workflow that self-tests itself and attempts to deploy a simple hello world NodeJS application
• We also created a repository to showcase this action working on an existing project, to provide a value proposition feeling to developers using this product. The repository can be found here: https://github.com/nearform/k8s-kurated-addons-examples
• The example repository currently contains a simple hello world NodeJS application to showcase an example project

What is currently missing to finalize this item:

• Both the k8s-kurated-addons-action and k8s-kurated-addons-examples projects require a real Kubernetes cluster deployed somewhere where they could deploy to. At the current state this is missing and the actions on both repositories will fail.
• At the current state Tilt, the automation tool we used to build and deploy the containers starting from the source code, has a limitation that cannot build and push a container to the registry, if there is no Kubernetes context available. It is not yet possible to disable this feature, even though there are demands for it ( see Question: Is there a way to skip the kubernetes context check? tilt-dev/tilt#3066 ). It would be interesting to explore how to unblock this functionality as it will be required down the road to have containers available to perhaps be tested elsewhere than the default given Kubernetes context.

By having at least these two points correctly implemented, it should allow us to be able to test our action "in action", as well as showcase easily to developers the action integration onboarding this project.