Rethinking the deploy to live production flow in Wappler 5

Request For Comments
1

We want to change the deploy/publish to live production in Wappler 5.

Instead of switching target and doing deploy, we want that the user always work on local development target and when ready to deploy to live, he should click on a different button called “publish” and then be presented with new dialog to deploy to live server in single step.

The new dialog will let you choose to which live target you want to deploy, enter version and do it in one step with commit to git, version stamp, deploy and database migration.

Does this sounds good? @wappler_ambassadors

And does it fit your flow?

13 Likes
2

I assume this is for Docker. Has no relevance for me if it is. I always work on local and then hit publish to push live now. How does that change things?

Edit: Not saying it’s bad. Just not sure it improves anything for me. :wink:

1 Like
3

That sounds excellent but can the various parts be made optional? Having git, versioning, database, etc. all in one go sounds perfect but I know there will be times when I’ll want to publish the files but not the database or maybe do git separately. Maybe a list of checkboxes with a ‘check all’ option?

1 Like
4

This already works very well with Targets, is it more for practicality?

5

@brad, I don’t use Docker but didn’t read George’s post as not relevant to me.

6

I have some projects where they're set as development so when I save it automatically uploads it to the server. Can this still be available?

1 Like
7

It fits and it just makes sense.

I only use targets for one simple thing: apply migrations.

8

How does this work if all your targets use the same database and you don't use the DB manager at all?

1 Like
9

Sounds like a winner for me!

10

A typical project for me has three targets - local (using MAMP), live and staging. I’d need these to still be available.

3 Likes
11

Sounds perfect!

12

Sorry, lots of posts from me!

The actual workflow works for me well at the moment. The only improvement I would like is a more visible status showing which target I’ve got selected. I’ve worked on projects and had the wrong target selected and published accidentally before realising. Maybe a thin coloured bar across the top of the whole program which is customisable? I might have my staging as yellow or orange, the local as green and the live as red.

5 Likes
13

At first glance it seems quite convenient. Wishes that the details of the remote target can be saved during deployment (as the targets are now), so that you do not have to fill in new details every time and you can choose from several remote targets.

14

Can’t you already do that? I have multiple targets set up and only enter the connection details once for each target. Am I misunderstanding?

15

Well if you use ftp the publish you work indeed the same only that you will get a popup dialog where you can choose the live target and enter version to commit if you use git and indeed have a checkbox to apply database changes as well.

The advantage is that you don’t have to switch targets so you basically stay always on local target and that is why we will be removing the dropdown to select the active target as it is no longer needed.

2 Likes
16

Right. I would like this to be preserved in a new approach in relation to the deployment of live targets.

17

Been hoping for this for a long time…I think it is much better to separate the dev process from pushing to production so the user visually experiences something different as a reminder that this should be considered more carefully. Thanks for adding this!

One thought on workflow. My personal approach is that the main branch always represents what is deployed to production, with no exceptions. Therefore I push to production, and then confirm it is all working properly before merging to master, to allow for rolling back. If I see issues with the push, I rollback and Master is not changed, so it still represents what is in production. If all is good, I go ahead with merging to Master.

I’d like to be able to retain this in the new deploy process. In other words, let’s make sure the new deploy process accounts for rolling back, not just moving forward.

1 Like
18

Yes exactly- the target details remain all the same as they are now. The choice for which target to publish to only moves to a popup with more publishing details instead of having it on the publishing toolbar below as dropdown

2 Likes
19

Well that is exactly what we plan to do in the publish step. Also tag the commit with a version number as well.

Then we can also have a “rollback” option that you can use to revert the publish to previous version and also undo the database changes as well.

Have to find the best place for such “rollback” option.

5 Likes
20

First, I do like the idea of always working on local target. I have gotten into the habit of immediately switching target back to local after publishing but of course sometimes I forget. So, that part I definitely like.

My typical work flow is:

Development Environment

  • Local MAMP Server
  • Remote Live Database

Publishing Process

  • Develop on Local
  • Switch target to Remote
  • Click on Publish (using ftp to push files)
  • Switch target back to local
  • Check remote to make sure everything is working
  • Enter description and commit to GIT
  • Add tag with version number to commit
  • Push Git to Remote Repository
  • Database remains unaffected

New workflow (If I understand correctly)

  • Develop on local always
  • Click on Publish
  • Choose remote target (Can local target still be selected to publish to?)
  • Enter Git tag with version number (what if GIT isn’t used?)
  • My live database is not affected
  • That’s it?
2 Likes