omega8cc
Add OpenDevShop support
This was originally requested a long time ago, so let's make this happen!
Some related issues:
https://github.com/omega8cc/boa/issues/439 https://github.com/omega8cc/boa/issues/720 https://github.com/omega8cc/boa/issues/473 https://www.drupal.org/node/1935810
After working with both platforms for a bit i'd say combining OpenDevshop and BOA is not a practical idea. The best direction now for BOA would be better git support.
OpenDevshop currently has the best front-end for Aegir. AND you could get the Devshop Devmaster front end running on BOA. But we need to focus our energies, so does it makes sense for two projects with so much in common to spend extra time shoehorning Devsmasters frontend into BOA, OR would be a waste of effort?
As a long time user of BOA (2010) i'm torn, I am grateful for both and would like each project to succeed on their own terms... but i guess i have to say is what i'd like to see now is a BOA playbook for OpenDevshop.
What are all the best features of BOA, let's write an Ansible playbook.
@arttus -- We don't see any duplication/waste of effort here. Why not to support it like we support vanilla Aegir?
Not sure what you mean by "The best direction now for BOA would be better git support"? It is not related to BOA, but to Aegir, which happens to be the control panel for Drupal we support. Maybe Aegir upstream could improve git support, or embrace ideas from OpenDevShop?
OpenDevShop has a nice concept and front-end, but it doesn't provide any advanced system/server level features BOA provides, so both projects and their users/audience could only benefit from working together.
As for Ansible, it was discussed in the past. Basically, it is not the right tool for BOA (too limited) and there is no benefit in rather big effort needed to cut BOA monolithic bash spaghetti into pieces (modules and roles) Ansible expects. BOA could benefit from a fundamental rewrite, but why exactly should we translate it into Ansible playbooks/modules/roles? We should rather focus on converting as much as possible into deb packages, remove old cruft and overcomplicated workarounds you are not going to translate to Ansible language anyway. Then we could take a look again, if such idea still makes any practical sense.
@omega8cc yeah I just meant with everyone's workflow pretty much solidly based on git, if BOA had better git support it would be much easier to use. Not sure how much work this integration would be https://www.drupal.org/project/hosting_git.
Totally agree about OpenDevShop being more of a developer tool then a production environment.
If adding OpenDevshops DevMaster front-end to BOA is a relatively simple matter like supporting vanilla Aegir's front-end then that would be a very useful addition indeed.
I was also thinking about the fundamental difference between the two projects, and i wasn't suggesting cutting up BOA's scripts into a playbook as much as building a high performance playbook that was designed with all of best features of BOA.
If deb packages make more sense then Ansible, maybe that's a better way to go, I wouldn't know about that level of detail of BOA's internals.
I forgot to mention why designing a new playbook for BOA comes to mind, OpenDevshop already supports it.
ubuntu@devshop:~$ sudo bash install.sh --makefile=devmaster-BOA.make --playbook=playbook-BOA.yml
@arttus The hosting_git module is included since BOA 3.0.0 (but not enabled by default) however it is far from being feature complete and production ready -- at least for most users.
We have recently un-forked as many BOA modifications introduced in Aegir as we could, so they are now part of vanilla Aegir, and this process will continue for any future modifications, so BOA will try to be just the clever server stack, ridiculously easy to use, supporting both vanilla Aegir and OpenDevShop, since they both are (at least so far) for very different workflows.
It is easy to forget when you prefer Git and monolithic based workflow, that the most Aegir end-users (and we host enough Aegir servers to be able to say this) actually love the fact that they are not forced to follow Git based workflow, and that they can use also the very classic vanilla Aegir approach. So, Git is not "everyone's workflow", in real world.
That is why we want to support both those end-users and more advanced developers audiences.
@omega8cc so can we hope for OpenDevShop support for BOA in the foreseeable future then? Like in Spring 2017, as the Milestone date for 3.3.0 is tentatively set to Feb. 1 2017? Or is this rather dependent on progress on all other issues first? Would be good to know your plans for this, to know if it is worth the wait or I should actively be looking into alternatives if we can't expect this to happen soonish.
@heliogabal The milestones are not really set in stone -- we are using them as moving groups of features/issues. This means that while current ETA for 3.3.0 is Feb. 1 2017, we may release it before Christmas, this year, because we expect to significantly accelerate BOA development in December. It is not a promise, but it is a strong intention, and our goal.
@omega8cc that sounds very promising! So I'm looking forward to the new features and wait.
We have recently un-forked as many BOA modifications introduced in Aegir as we could, so they are now part of vanilla Aegir, and this process will continue for any future modifications, so BOA will try to be just the clever server stack, ridiculously easy to use, supporting both vanilla Aegir and OpenDevShop, since they both are (at least so far) for very different workflows.
I'm just curious. An scenario can be using OpenDevShop on a local machine for development, another machine (virtual or not) using BOA + OpenDevShop as a staging environment to simulate the production environment, and one of the enviroments (production) can be the public BOA server without OpenDevShop? Or in order to sync OpenDevShop it must reside on both ends? if not, so it can work on current BOA? (deployment)
Silly question since I don't use OpenDevShop and as I'm a freelancer my dev workflow is pretty simple; now I'm changing my workflow because I'm now deep learning D8, so I'm more interested in this kind of tools, guess I'll start using devshop.
Currently, you can't automate the workflow between OpenDevshop and BOA. You'll need to login and manually update your BOA production instance with a git pull.
@arttus asked that in gitter yesterday, jonpugh pointed that as far as BOA has aegir_git maybe there is a possible way to deploy.
@yaazkal I would also be very interested in this functionality.
I haven't spent much more effort than my initial discovery and realization that they don't currently play well together.
You wouldn't really be using OpenDevshop for deployment in this case as much as just using a git webhook. You'd still need to manually setup the site in BOA but If aegir_git can be used to receive the webhook that does the git pull, and control the branch or tag that would at least be a start to getting the two to work together.
There is also the issue for Drupal 8, that composer would need to work on BOA (if you're using composer), or you could just commit your vendor directories, which is what I'm doing for now.
@arttus yes, ouf course I need to have some time to test and see how can be a good workflow for each other even if there is a last step to run manually on live. By now as I'm only keeping make files and composer files on git, devshop will not help me unless I start to change my dev workflow and my git structure. So I'm reading, testing ODS and see how can I use it.
I'll have some time soon to see how can be a possible way to use them togheter for better development, but at least hosting_git (I wrote it wrong the first time) can help.
@yaazkal Have you tested ODS? Does it makes sense to use it for dev/stage/live workflow? Do you use ODS locally also or have something like Acquia BLT with Drupal VM for local? Do you think BOA + ODS make sense?
@Pls hi, I've tested ODS but in 2017, so for sure it is very different today.
I guess that it can make sense according to your own development workflow, but also if you work with a team, and if you want to autotest the site (but maybe a grunt task or similar can do the trick on autotesting). One think that I didn't like about it is that all code should be present in the git repo (I mean drupal code and modules, etc), I prefer clean and lightweight repos (I use composer + config sync).
I do not use ODS today because of my simple workflow and because mainly I develop alone, so at the end I didn't wanted to overcomplicate the process. At first I was using WSL (with custom scripts to automate site creation plus nginx configuration, etc) on Windows 10 but it was pretty slow due to the way WSL manages files, then I used WSL + unison in order to autosync a folder to the "local" WSL subsystem and performance was ok; after something crashed my WSL system I ended up using Acquia Dev Desktop and I'm fine with it. It uses Apache instead of nginx but is ok too. I just code locally, test, git push and then git pull on the server, then composer install --no-dev and drush cim if needed (60% of my sites now are in D8).
So again, if BOA + ODS will make sense is just a personal/team matter that everyone should decide according to its needs. I shared to you my experience so maybe if it can make you take a choice.
Now, if ODS should be a feature of BOA that is another issue, I think that it can be a cool optional feature.