Wouldn’t it be great to have versioning, a history of changes to the site, ability to work with multiple developers and integrate code from all of them. Using Git, and more specifically GitHub could help with this.
It would be great to see GitHub integrated into Treepl. I could imagine an integration similar to Heroku, where you could push to the main branch of you repo and it could automatically go live.
I guess then we would need to account for users who make changes on the site. My first take on this is that if a GitHub repo was connected to a site, then when users make changes through the admin interface then it commits and pushes those changes to the repo.
Use cases:
-multiple developers working on the same project.
the need to roll back changed to an earlier version.
I say GitHub, but this could just as easily be Bitbucket or GitLab integration also.
I would love to get feedback from other Treepl partners before submitting this to the backlog. Does anybody have any additional use cases that would benefit from GitHub integration? Are there any specific features you would want if this was developed?
My experience with GitHub is very limited. I have only used it to download different projects that I could use, but have never worked with it where it was “integrated”. Would like to hear more about this and how one would work with it. Without knowing more than the basics it sounds really interesting
To give a bit more detail on how GitHub integrates with Heroku.
It’s really straight forward, you add you GitHub credentials, you manage a few settings (like the environment, but obviously that wouldn’t be the case on Treepl because it’s one environment), then you click deploy and all your files from your GitHub are deployed to the live site. Then you can set it to auto deploy when somebody pushes to the main branch, essentially keeping your site right up to date.
I imagine you could also use this a development environment option. You could setup a dev site with the same repo and automatically deploy to it when you push to the main branch, then when the dev site looks good, you could manually deploy to the live site.
I’ve just implemented github integration for our Treepl sites. This uses the “grunt” nodejs task runner framework and uses FTP to download the files from a Treepl website to the local git repository. We then commit changes and push to github. This gives us change history.
As a part of this I’ve implemented a nodejs webserver that allows a TreePl website to run locally. This improves our development productivity as it allows us to use local development tools and makes using sass easier (no more uploading files to Treepl to see their effect!). The nodejs webserver knows how to process pages into templates and snippets into pages. It doesn’t handle any other liquid markup or modules, but we don’t use that with our development anyway (we let Vuejs do that for us).
I’m working on an automated uploader of changes back to Treepl to close the loop on “proper” source control.
@Allistar Thanks for your reply. I use gulp which I think is quite similar to grunt.
So you automatically pull down the site via FTP on a schedule and then automatically push those changes to your local repo? That’s an interesting idea.
You’re using Treepl in a really interesting way. I don’t think I could use it without modules and liquid. How are you using Vuejs as a replacement for modules and liquid? Are you using an external database?
Would you find it a benefit if Treepl had GitHub(GitLab/Bitbucket) integration in the way I described?
What about having reverse integration, so that if admin users make changes, that generated commits and pushes them to a repo? (I’ve never actually seen this implemented, it just kind of came out of my imagination on how to handle user changes and have them not be overwritten)
I guess this raises the question of what would happen if a user pushed a change that conflicted with a change that a dev pushed directly to the repo. Would they have to be notified in some way? Would they need the ability to resolve conflicts?
I’ve always found it tough to use CI options. I tried to use BitBucket to deploy to a Treepl. There is a lag to preview changes (I think it was like 10s or more) and you really need to see changes live on the site to see what they’ll look like. I wonder how this service would be FTP Deploy · Actions · GitHub Marketplace · GitHub . I’ll put it on my long list of things to try when I get time.
@James Agreed. Staging/Production environments would solve my problem mostly.
However I still think there is a case to be made for a good Git integration. While I’ve come up with workarounds (VSCdode Liveshare), it’s not an ideal solution, and for more traditional workflows where multiple developers are working on the same site, Git allows this kind of collaboration, versioning and rollback. It’s an existing system that developers have been using and are used to, so I think you get the benefit of leveraging a system that could be considered a defacto industry standard.
We can download an individual site or all sites at once. We tend to do this when we start working on a project for that site. It isn’t automated run on a schedule. The command we run is: grunt download:site:live
Where “site” is the name of the site and “live” can also be “test” or “staging” if such a site exists for this client.
We use modules but they’re not the core of our sites and so excluding them from our local development isn’t a big deal. We integrate to a server based system via an API and use the power of Vuejs to build the integration between the front end and the backend. So we use very little liquid markup. Nearly all of our snippets start with {%raw%} and end with {%endraw%}
We’d like to retain the ability to develop locally. It’s very cumbersome to not be able to world class editors and tools like compass to convert scss files to css. Without local development when we make an scss change we then need to compile this to css, upload the css file(s) to Treepl and then refresh the browser page. That slows down development. Now we change the scss file and a file watcher picks up the change, and the “grunt:server” tool we’ve written sees that a file has changed to it automaticall refreshes the browser. This is a much more efficient development flow.
What’s missing is an easy way to upload the changes back to Treepl.
Git integration from Treepl would be great, but it needs to be as powerful as local git. I.e. branches, stashing, tags, full git history etc.
That would be far better. A development flow like this:
we develop locally
push changes to a git repo in a feature branch.
have those changes peer reviewed via a pull request.
merge the branch to master/main
tell Treepl to “pull” the main branch.
A shortcoming at the moment is that not everything in Treepl is stored in a file in the file system. E.g. the templates a page uses.
There are dozens of world class tools that solve that problem. But they all tend to run on local repos.
Perhaps I didn’t express myself clearly. I wasn’t suggesting that local development wouldn’t be possible. If anything I’m trying to find ways to expand local development possibilities. I’m suggesting something more along the lines of the example you gave:
That would be far better. A development flow like this:
we develop locally
push changes to a git repo in a feature branch.
have those changes peer reviewed via a pull request.
merge the branch to master/main
tell Treepl to “pull” the main branch.
There are dozens of world class tools that solve that problem. But they all tend to run on local repos
Again, I think I wasn’t expressing myself clearly. I’m trying to figure out what to do if a developer is working locally and pushing changes to a live site via a pull request to a main branch, or just a direct push to a main branch that deploys to a treepl site, and simultaneously a person in the admin make a change that conflicts with a change that the developer made. My suggestion was that changes made by users in the admin would be pushed to repo automatically. Being that this would be some kind of automated process, user in the admin wouldn’t directly interact with the repo, so they wouldn’t have any conflict resolution options. I think this means that the conflict resolution would always be on the developer interacting with the repo to do conflict resolution.
I’m just pinballing here and I’m not sure if this is a sensible solution.
The issue I’m trying to solve for is when a developer is making updates to a site via git, and those updates are pushed to a branch and deployed to the live site, but at the same time there might be a use in the admin making changes. How would those be handled. Especially if there was a conflict.
Option 1 is to not handle them and have developer be mindful that their changes could overwrite changes made by the admin. So they would have to download the site at the start of their work session and know whether or not there are users in the admin making changes during their work session.
Option 2 is something like I suggested above where changes made in the admin of a site are automatically pushed to a git repo.
Neither of these seem very good and I’d love to hear what people think or if they have other better ideas.
You’re right, that’s an issue that would need solving. In our use case we allow some clients to make changes themselves and they wouldn’t have the knowledge required to deal with conflicts. I can think of a couple of solutions:
Make it so that TreePl can’t pull from the github repo unless all changes in it have been pushed. I.e. Treepl does the equivalent of “git status” and if there are any uncommitted changes then a “pull” can’t be done. Since pulling from the repo would be triggered by a developer that knows how this works then they can correct it by first pushing the changes made in the admin pages. They can then do the merge conflict and then do the pull.
or
When pulling from the github repo have the Treepl user interface to the merge to a staging (i.e. unpublished) website when the dev can fix up the merge conflicts before “publishing” the changes (making them live). I expect that this will take much longer to implement than the first option.
I think this is too dangerous and will more likey result in lost changes.
Getting this working would make a massive difference to developers of complex high functionality websites such as us.
Thanks for sharing your ideas @Allistar. I think productive conversation like this is extremely useful when trying to flesh out more complex feature requests like this.
I would love to hear if any of the Treepl developers have thoughts on think about this? Does this make sense? Are some suggestions much easier/harder than others? @vlad.z@Eugene ?
Is there a plan to allow for local development? I would have thought this would be problematic as Treepl would be essentially providing their server side code/executables which people could then potentially use in a production environment outside of the Treepl platform altogether. From a business point of view this wouldn’t make sense. Unless running it locally somehow reduced the user experience (e.g. make is slower, add in watermarks etc).
For us we can run the websites locally as the only feature we use is templates/pages/snippets and dealing with them in a simple nodejs webserver is easy. We don’t use liquid and I expect most Treepl users do.
@Allistar I haven’t heard any plans for Treepl to allow for local development. So that point should be made. This would be in the context of continuing to use Treepl servers to view/render the site. The workflow would be to have developers push to a development branch that automatically update the development site when pushed to. Once the development site is looking good, then the update could be pulled/pushed to a branch that would make the changes to a live/production site.
So something to consider is that if developers where using this as a primary way of viewing a site during development, then it would need to be relatively quick. If it’s really slow then the application would be different. If this process is slow, then I think during development it would still make sense to ftp changes up to a development server to get instant updates and then push changes to a repo. Then it’s primary utility would be to push changes to live server and keep a version history. Then also to roll back changes if need be.
My thought is that deployment could be pretty quick, but I don’t really know that.
