We are using Okteto as much as possible to manage our development/testing environments. It would be very convenient for our developers if there would be a possibility to trigger certain actions from the Okteto UI. We do for example have some scripts that:
- Reset or provision some resources/test data in the development/test environments
- Run tests
- List kafka topics
- etc…
The script could be some script that has been added to our custom Okteto runner image. But often these scripts should be run from one of the containers that are deployed in our Okteto development/testing environment. Therefore the developer needs to:
- know from which container to run the script
- open a shell to the specific container and run the script from there (possibly using kubectl exec)
- Manually type options/arguments for the cli command
Currently we have implemented some additional Okteto manifests that contain a deploy section only (in the deploy section there is a single line to run a command using “kubectl exec” in one of the containers in the environment). Additionally we have configured catalog items for running these actions/tasks. Examples of our current catalog items correspond to the tasks listed above:
- Reset test data
- Run system-tests
- List kafka topics
- and more…
The advantage is that the developer can simply run the action from the Okteto UI and does not even need to know where the actual script resides. And because we can set some default variables there is no need for the developer to manually type the options/arguments for the cli command. In other words, the functionality could be implemented by someone who is responsible for improving the developer experience and this person could simply provide new functionality by adding it to the Okteto UI. Developers do not need to know about the technical details.
In other words, we are “misusing” the “deploy dev environment” option to trigger certain actions/tasks in our development environment. The reason is that just clicking a button in the UI is very convenient for our developers and thus it improves the developer experience. But I think from a UX perspective it would be nicer if these “action/task” buttons would be separated from the buttons that actually deploy certain resources to the environment.
Visually it could be implemented as following.
- Add an additional item with a name “Tasks” or “Actions” next to the “Deploy dev environment” item.
(Would have liked to add an example image here but unfortunately I’m not allowed to add images to the post).
Here we can select a task/action to add to our dashboard (for the current namespace). However, instead of immediately running the task it will only be added to the dashboard. (In this way a user can choose the tasks that he/she wants to add to the dashboard).
- When a task is selected a button could be added for this task in the top bar (next to the redeploy and destroy icons).
(Would have liked to add an example image here but unfortunately I’m not allowed to add images to the post).
Now when the user clicks the button for the task he/she will see a dialog similar to the dialog for the “dev environments”. Thus the dialog where he/she can add the repo-url, branch, variables and manifest path (technically a task is implemented in the same way as a “dev environment” therefore this dialogs will look identical). The only difference between “dev environments” and “tasks” is that a “dev environment” usually deploys some resource to the environment while a task will only run some script. Therefore in the dialog there could be a “Run/Execute” button instead of a “Deploy” button.
Conclusion: we want to separate the “deployed resource” buttons from the tasks buttons in the UI because it improves the user experience.