How it works
From an empty library to a pushed repository
Here is the whole path, step by step, using a Membership CRM as the example.
The walkthrough
-
Start a library
Add the fields you use everywhere: First Name, Email Address, Status, Date Of Birth. Give each its type and validation, then publish version 1.
-
Bundle what belongs together
Group First Name, Last Name and Email Address into Contact Information, so every entity that needs it gets it in one step.
-
Make your entities
Create Member and Membership from properties and bundles. MVC Builder names the model and table for you.
-
Attach features
Give Member CRUD management, search and soft deletes. Give Membership an approval workflow and notifications.
-
Assemble the package
Add both entities to a Membership CRM package, relate them, and lay out the create and edit views.
-
Review before building
The pre-deployment review checks the package. Errors block the build; warnings are listed for you to decide.
-
Generate
The build writes the models, migrations, controllers, routes, views, policies and tests, then runs the tests.
-
Push to GitHub
A separate step pushes to your repository, opens a pull request and adds a GitHub Actions workflow.
What you see along the way
-
Pre-deployment review -
Deployment progress, pushed to GitHub -
Test results and coverage by entity -
Generated code with provenance
Questions developers ask
Is the generated code mine?
Yes. It is ordinary Laravel source in your own repository. There is no runtime to install and nothing to license at run time.
What happens when a library item changes?
It is published as a new, immutable version. Packages that use it are told an update is available and choose whether to accept it.
Can a deployment overwrite my changes?
No. Generating and pushing are separate, deliberate steps, and changes reach your repository as a pull request.
Where are secrets kept?
They are referenced by name in the generated workflow and never committed to the repository.