@Alex_B_Centrifuge all good points.The speed of making a change to the content and seeing it on the browser is critical for this to be useable for more than just change tracking. In a normal github flow we wouldn’t need to commit and push our changes in order to test them. We should be able to develop, test, develop, test, peer review then deploy. With a local server I can make a change to a snippet and within 500ms the page refreshes and I see the change. We don’t want every little change to result in a git commit, that would be very unproductive
If we assume that Treepl won’t provide a local viewing capability then we’d need the Treepl admin interface to be a lot smarter and have git integration built in. I.e. we can make changes in the admin interface and then commit them to a repo and push them. This would effectively make the admin interface “git aware”.
There are three main development issues I see that need solving:
- change tracking and a review process. This gives the ability to roll back changes and see the history of a site.
- The ability to use world class editor software (e.g. VS Code, Eclipse, Atom, Sublime etc) and other local tools like compass for scss → css compilation.
- To be able to view our changes nearly immediately in a browser. A quick turn around between making a change and seeing that change is critical for efficient development.
Git integration gives us the first point but it doesn’t help with the second two.
On reflection, there is no way that deployment would be quick enough to expect updates to that are pushed to a main branch to be deployed at a speed that would facilitate viewing those updates.
@Allistar You are absolutely right, you wouldn’t want to have every change committed to a repo to see it on the live site.
Without local development option, likely those who are using and IDE and Treepl features will continue to have to push to a development instance with FTP until they are happy with their changes, the commit and push an update to a main branch that could be deployed to a production instance.
Revised scope for Git integration:
- Deploy to a production site when updates are pushed/pulled to a specific branch.
- Changes made to the site in the admin to be pushed to a repo.
Really the first case could be mostly covered by services that already exist, Bitbucket pipelines, GitHub action etc. So this would really be a convenience feature.
So really we’re looking at 2)
The main benefits of this would be change tracking.
There is already a feature scheduled to come out in the next development sprint for page rollback. So this may already be covered in one way or another.
At the end of the day, I don’t see this feature being practical. I’m not sure the juice is worth the squeeze.
I really appreciate others for taking the time to chime in. Especially @Allistar . This conversation has been really productive.
Of course I’d be open to hear what others think. Maybe I’m off base with my conclusion.