Build, Deploy and Release XX

Build and Release (after all artifacts)

Screenshots of the Kanban process workflow

After testing this issue and seeing everything works as expected, we can move the issue to Review. The Review status is like a parking lot for issues waiting to be merged to the production code. Let’s now move the issue from the Review status to the Release status. After doing this, TENUM® will automatically merge the changes in the source code from the issue to the production environment. Congratulations, you just merged your first issue! After merging, the issue test environment is removed and the production environment is updated:

Gravejard Stuff

IDE explained

• Job Manager

• Test Panel

• Shortcuts

• Features

• AI integration

TENUM® provides a web-based Integrated Development Environment (WebIDE) that you can use to develop your applications. Features include: Code Editing: Write and edit your code directly in the browser. File Management: Organize your project's files and assets. Real-Time Preview: See changes in your application as you develop. Integrated Tools: Access testing, debugging, and deployment tools within the IDE.

There are several things to address here.

1. Test Panel - this is a test panel to see tests that you have added to your project. Test files end on .spec.lua extension. Currently, the test panel is empty since this is a new project that does not contain any tests. Here you are able to see which tests have passed and which tests have not passed. You also have filtering functionality and other utilities. We will come back to this later.

2. Log Panel - this panel shows logs for the running production instance. Since this is just a hello world project without any additional functionality or added logs, the Log Panel is empty. We will touch more on this later.

3. Initial.uie.lua - this file is basically what is deployed to the production instance. We will revisit uie.lua files later, but for the time being, let’s just preview the basic characteristics of these file type. Basically, uie stands for “UI element” and these file types are how you develop the frontend/UI of your application. We use React under the hood, so the uie.lua files are just a DSL in Lua for React components. You have 3 functions that are possible to implement for uie files - init, update and close. The only mandatory function that you must implement is the init function. Most of the time you will also implement the update function, and only sometimes implement the close function. These functions are lifecycle hooks for the component, with init being invoked only once during (you guessed it) initialization and update being invoked every time the props of the component change. The close function gets invoked only once, when the component is destroyed. You define the components that the uie file should render as Lua tables inside the state.ui.props table. There are multiple predefined types each ui component can be set to, we use the Chakra UI component library under the hood for the more common UI components modern applications use, but also we have several libraries for more complex UI components, like diagrams for example. To see an exhaustive list of available components that you can reference in your code, check out our storybook! You can also find a playground to use the components there from Lua 😉!

4. Utility - here you have a button for switching the IDE to dark/light mode, or going into full screen mode.

On top of this you can also click on the “File” button in the top left corner of the IDE. You will see a dropdown list containing “Save” and “Save All”. The save button saves the current open file (if it is changed of course) and the Save All button saves all the modified files that are opened as tabs in the IDE. In this dropdown you can also see the hotkeys you can use for these actions, instead of manually clicking.

Files that are modified have the atom icon changed to white, to indicate that there is a change to the file, and we also have a git-like gutter to indicate the lines that have changed.

If you try to close the tab of a modified file without saving it, TENUM® will prompt you that you will lose all your modifications if you continue.

11. Testing & Debugging TENUM® supports automated testing and debugging through test cases or spec files: Spec Files: Create alongside artifacts to define test functions. Automatic Execution: Tests run when the spec file or corresponding artifact changes. Reporting: View test results in the test panel within the WebIDE. AI-Assisted Testing: Use AI to generate test cases for your artifacts. Debugging Tools: Integrated tools to help identify and fix issues in your code.

After testing this issue and seeing everything works as expected, we can move the issue to Review. The Review status is like a parking lot for issues waiting to be merged to the production code. Let’s now move the issue from the Review status to the Release status. After doing this, TENUM® will automatically merge the changes in the source code from the issue to the production environment. Congratulations, you just merged your first issue! After merging, the issue test environment is removed and the production environment is updated:

12. Deployment and Rollback Manage your application's deployment lifecycle: Stages: Develop: Implement and test new features. Review: Submit changes for peer review and approval. Release: Deploy changes to the live environment. Preview Environment: Test changes in a safe, isolated environment. Rollback: Revert to previous versions if issues are detected. Future Enhancements: Upcoming features may include automated testing gates and AI-assisted fixes.

Project Repository

Anatonmy of an App

• initiakuie.luae

1. Namespacing

• TENUM® uses namespacing to organize and encapsulate related artifacts, such as entities, message handlers, and UI components.

• Namespaces are derived from the module or feature they belong to, ensuring a clear hierarchy and avoiding naming conflicts.

• Example:

  • A Todo module might have the namespace todo.api, with artifacts like todo.api.todoEntity and todo.api.createTodoHandler.

All you need to get started is a project within TENUM® that contains your repository [TT]. Like a Github repository it is a file and folder based structure to organise your projects code.

Each file is written in Lua and represents an artifacts [TT] such as entities, ui element, message and event handlers. And each artifact plays a specific role in application development with TENUM® (see below).

The initital.uie.lua File.

Folder Structure

2. File Naming Conventions

• File names are descriptive and follow a consistent convention to indicate their purpose and association with artifacts:

  • Entities: EntityName.e.lua (e.g., todoEntity.e.lua)

  • Message Handlers: HandlerName.mh.lua (e.g., createTodoHandler.mh.lua)

  • UI Elements: UIComponentName.uie.lua (e.g., TodoList.uie.lua)

  • AI Handlers: AIHandlerName.aih.lua (e.g., createAiTask.aih.lua)

  • Decorators: DecoratorName.d.lua (e.g., LoggingDecorator.d.lua)

  • Tests: ArtifactName.spec.lua (e.g., todoEntity.spec.lua)

• This naming convention provides immediate insight into the file's purpose and role in the application.

3. File Structure

• TENUM® encourages organizing files into directories based on modules or features, promoting modularity and reusability.

• Each module typically has its own directory, containing all related artifacts:

  /modules /todo todoEntity.e.lua todoListEntity.e.lua createTodoHandler.mh.lua todoList.uie.lua createAiTask.aih.lua LoggingDecorator.d.lua todoEntity.spec.lua module.lua

• Supporting files, such as configurations or utilities, are also grouped within the module directory or in a shared directory if used across modules.

URLs and URL handling

FE Development „Very very close to next.js and ReAct“

• How to CSS

• Craft Editor

• Storybook

BE Development

AI Development within an isse