I would really like to see a synchronize function similar to what dreamweaver used to have. I should be able to pick any target, and then compare the local files to the web server files and wappler tells which files don’t match? That would be very useful.
2 Likes
Like it.
I am quite supportive of the idea other than i am uncomfortable about losing the target dropdown.
Sometimes i do like to switch to production and check everything is as it should be or indeed to download a file back from production (i know git will allow this but i like the flexibility and i don’t tend to use git for smaller projects, only larger ones)
I am also l a little concerned about the reliability of the database manager if losing remote access. It does, from time to time, screw up and i like the ability to reset changes
maybe best to add the new functionality first then remove the dropdown/target access later when tested over time
1 Like
Yes I wouldn’t like to lose being able to switch targets, I feel like it would be losing control / flexibility
Yes for the ftp manager, we have a drop down to switch to remote target, we might there just add the live target names, so you can download from there.
Same maybe for the database manager. We can add target dropdown to its own toolbar so you can switch and check this targets database structure or view data.
Other that that you probably never need to switch to remote and only publish to it as outlined above.
That scares me a little. Instead of one target setting to worry about like now there would be multiple.
Working on local, file manager set to production and database manager set to staging for example. I can see some horrible things happening.
Scary stuff for me anyways. Not sure about that. As you say I’d likely very seldom have to switch to remote in the new scenario. How would your prevent being connected to three different targets at once?
If I read the change correctly, nothing changes except that when I click on Publish, I get a reminder of where to publish to.
I often Publish only to find out that the remote has not picked the modification up due to me forgetting to change the target.
I like the new workflow idea, but it would also be nice to keep selectable targets as it is now
For example, one might want to access the terminal of a live target (I don’t know if that’s currently possible, never tried), so in that case, the ability to change targets to check the terminal seems nice
I used that function a lot in DW and I miss it…As i don’t build big projects and don’t use git but some kind of “synchronize/file compare” would be useful for me too.
1 Like
I like the idea of being presented with the options to choose targets when publishing a project. It seems from the discussions so far that this functionality will also involve migration of database changes along with other changes.
As @brad mentioned previously, I do not use Wappler’s in-built database manager. So, there’re no db migration changes that will get pushed to the published targets. Will the new flow provide options to check/uncheck individual parts of the project to be published?
1 Like
Sounds Super Great imo!
The whole conversation has me confused.
Without the target switch, how will I set all the globals?
Maybe some screenshots on how the flow will look like would help.
If you are considering changing the publishing flow, it would be best to not add another way of publishing (Git) with that release.
There is no Git based deployment setup in Wappler at the moment, so either release just that first… let the users be comfortable for a month or two… and then change the publishing flow.
Or, work on changing the flow only. And add Git options later.
I am pretty sure no one is waiting for Git deployment options except like 4 of us. So we can wait a bit more.
I would keep the current system as-is. Nothing changes for users that don’t want anything changed.
And start working from scratch(new files, new code) in a new deployment functionality that follows best practices and current standards. This would be used by early adopters that can provide feedback as you guys iterate on the functionality.
In 6 months time once the new functionality is solid and proven to be the better way the old targets stuff is set as a legacy feature and the new one is provided as default for new projects. People can still use the old ones by selecting in project options. Until you decide to permanently sunset that stuff.
5 Likes
Hi George,
At a point in Wappler’s growth path, you may want to consider adding the concept of Roles, and use them to enable certain Wappler functions. In certain businesses, there is still a hard separation between development and deployment actions, including the access to data / connections to the Production databases.
Today, we achieve that separation totally outside of Wappler, and since it’s working well, having this done through Wappler would not be a priority for us, but wanted to raise it in case it is for others.
(In case you’re interested, we handle all this thus: someone in my org takes a particular code tag from the GIT central repository and assembles the scripts to deploy the code, including for example, the changes to the DB connection strings, which are unknown to the developers, and also the SQL scripts that would implement any db changes to Production – all of this done completely outside of Wappler.)
Many thanks!
1 Like
That is very interesting! If this could be done with Wappler, what will be your ideal publishing workflow and prolee of people involved?
1 Like
That’s a bit difficult to answer, because each organization likely has a different view of “ideal” and mine can be easily deemed irrelevant by the next one.
An important consideration is that what follows is unlikely to be applicable to the typical Wappler user today. I may be wrong, but I think that most of us are small shops for whom these constraints can be obstacles to getting things done quickly. Larger development shops, or even small ones where clients demand more formal processes, on the other hand, may find these capabilities useful. I am among the latter, but as I said, we supplemented Wappler with external processes, based primarily on OS scripts.
To accomplish the formality referred to above, I was thinking along three principles:
- There shall be a way to segregate the activities that a role can perform when using Wappler
- There shall be a way to constrain the visibility of the objects that a role can act on when using Wappler
- There shall be a way to properly manage authentication (login) and authorization (association to roles), and audit (selectively logging who did what and when) of Wappler users.
Ultimately, #1 constrains the “verbs”, and #2 the “nouns”, the objects of those actions and together, these 3 principles provide a large degree of flexibility.
Examples of objects: Regions (e.g., PreProd, UAT, Prod), configuration files, image assets, page files, Server Action APIs, Libraries, etc.
Typical verbs: Create, Read, Update, Delete, Publish to GIT, Deploy to Region, etc.
For example, one can use them to control, in a multi-developer environments, what type of objects can be touched by which developer (e.g., the common code can be managed by one specific group of developers, the pages by those who are good at creating UIs, and the APIs by those who understand back-ends better), but also, and perhaps more importantly, which role can connect to which database in each region, and make changes to its data, its structure (tables, columns, indices, triggers, etc.), its store procedures, etc. [Note: I realize that the latter may be rather complex to do well or to everybody’s satisfaction.]
Maybe certain flows can be configurable (perhaps using wappler steps designed for that purpose?), because they may be repeatable. For example, a deployment to production of a certain code set (let’s assume that no changes to data are required) may always follow a pattern like this:
- Assembly
- Test in separate environment
- Authorization to deploy to prod
- Deployment
- Communication of results
In an ideal world, all these (start and end time, objects deployed, reason, authorizations, etc.) will be logged.
Hope this helps,
Alex
One question: would someone actually pay for a Wappler license just to deploy?
A full stack role in that case will be ideal for many dev projects along with improved SSH connection for developer. For example vs code conveniently lists file structure on the server and enable editing of conf files on the server and also push project to target folder.
Current Wappler for me is most sensible platform. And I am someone striving to become a full stack developer with least resources. If there is too much tug-of-war between what future wappler should be, then you may want to classify users into groups, split paths and give each a version of wappler tweaked with features required by the group.
In Wappler 5.2.4 you can publish your project with a single click to any remote target, applying automatically database changes and even commit and version to git.
3 Likes