Capifony V3 (POC + Discussion) #437

Closed
wants to merge 17 commits into
from

Projects

None yet
@peterjmit
Contributor

(this pull request might be better made against a v3 branch, but I am not able to create one ;) @willdurand)

Capistrano v3 was announced in June and has many improvements that allow for capifony to be a much simpler layer on top of some already powerful tools.

v3 is still undergoing development and as such some current features in capifony are not possible however this pull request has implemented the most basic capifony features for deploying a Symfony 2 app and is hopefully a decent enough starting point.

This is a good opportunity to cut some of the cruft from capifony (Symfony 1 and bin/vendors) and make it a tool that is a little easier to use and more importantly maintain.

Check out the composer task or the symfony console task as examples of just how simple v3 makes some of the previously verbose functionality in capifony.

I have written a changelog that details the changes I have made so far.

@KingCrunch
Contributor

👍

I thinks it's a good reason to get rid of legacy code 😄 Also it'd like to see much less variables (means: Just assume things as convention).

deploy:cold - what use was this?

Initially: Think of a sequentiell :setup and :deploy. Something like "I need a new server and I need it now" and thats the fire-and-forget-command for that. However, was never really setup properly I guess? 😕

assets:install - Composer runs this in the symfony standard edition, is it needed?

If you want to manually reinstall the assets it is still required, but I would keep it out of the "root" and push it instead into symfony:-namespace.

Same for

bootstrap:build - Also handled by composer?

symfony:doctrine tasks

I once thought, that it maybe makes sense to strip out the doctrine-tasks into a separate cookbook (but also pointed out, that I don't want to do it :D) Maybe thats interesting?

composer_download_path - might change due to MITM problems?

I still have the opinion, that it isn't the job of capifony, to ensure, that the tools are all available on the server. I'd drop it completely and would only keep :composer_bin.

More composer tasks? (add warnings for deploys without a composer.lock file?)

Nice. Would like it.

@patie
patie commented Oct 29, 2013

+1

@nifr
nifr commented Nov 5, 2013

@peterjmit Could you elaborate "v3 is still undergoing development and as such some current features in capifony are not possible however" ?

Which features are not possible in Capistrano 3.x ?

@peterjmit
Contributor

Hi @nifr at the time of writing SSHkit was not complete (or just not documented) and so there was no DSL ready for uploading files to the remote server, or for running local commands.

Both these pieces of functionality have been since implemented so we are good to continue.


That aside I have frozen a little in continuing this PR because I am rethinking the approach to the update.

The core functionality for deploying is somewhat implemented as is (ignoring the lack of tests, or any bugs that may be present in my work). The maintainers of Capistrano have worked hard to allow modular libraries on top of capistrano core and I think this project and the community would be better served by taking advantage of that.

Ideally I would like to have capistrano/composer and capistrano/symfony maintained here: https://github.com/capistrano or at the very least available as separate gems/projects. Capifony can then still exist to make it easier to work with capistrano (for PHP developers), including the prettier output, and additional tasks that don't belong in capistrano/symfony or other libraries.

Would be interesting to hear what you guys think! (cc @willdurand) If this sounds good then I can start a dialog with the maintainers of Capistrano.

@nifr
nifr commented Nov 5, 2013

I had started writing a Capistrano 3.x compatible version of Capifony from scratch a few days ago before i came across this issue when researching for things that could be improved.

separation of concerns like ...

  • composer-operations
  • backup/restore a shared folder
  • database-operations like import/export
  • generic permission-operations

... were the first thing that came into my mind.

Configuring capistrano has always been googling for "capistrano+xxx" ...
... and in the end copying parts out of repositories providing the needed tasks ...
... plus 100 badly implemented totally totally useless (for my current application) other tasks on top.

A rewrite should respect and encourage others to implement the advanced modularity that Capistrano 3.x provides.

It's exactly what you're refering to i guess? let's make it right this time. I have been gathering a lot of information already like collecting all used variables in capifony, tasks in great need of improvement and other things to optimize in my private issue tracker. I wanted to create some structure in my collection before publishing it here.

If you're interested in collaborating we should do a quick hangout, mix up our ideas and maybe create a structured roadmap together.

Would be nice to hear your thoughts about a collaborative rewrite from scratch and the most important improvements on your list: @everzet and @willdurand

My reason to start the rewrite was the missing try_sudo / admin_runner and environment variable support in capifony btw.

@peterjmit
Contributor

@nifr I have already done as you suggest and re-written (essentially from scratch) the functionality - this is what this PR is about. Definitely take a look at what I have done so far, and contribute/improve from there (https://github.com/peterjmit/capifony/tree/capistrano-v3/lib/capistrano).

The composer stuff could (should?) be separated out, but apart from that the code I have implemented so far only handles the following core parts of a symfony deployment:

  • Sharing directories (logs, uploads)
  • Setting correct file permissions
  • Deleting non-production front-controllers (i.e rm app_*.php)
  • Providing an abstraction around running console tasks
  • Management of parameters.yml (WIP)

All other unrelated tasks/variables have been removed.

I am suggesting that this list of functionality should form a core library (capistrano/symfony), Capifony could continue as a library dependent on that core, adding "convenience" tasks, pretty output etc.

@nifr
nifr commented Nov 5, 2013

I would suggest moving permission handling ( chmod, chown, acl, ... ) and basic file operations like removing front-controllers to an external gem and only making use of it in capifony.

Setting permissions correctly and/or removing files for production occurs for every (web)-application deployment and a well written implementation could be useful for many other developers ( not limited to a framework like symfony2 or even PHP in general ).

We would totally benefit in the long run if a bigger target-group could use these file/permission tasks and in turn helps improve it. Things like the missing debian support for :chmod permissions caused by the use of +a would affect more users and in turn a PR fixing it would be more likely.

What do you think ?

@nifr
nifr commented Nov 5, 2013
  • handling of parameters.yml

I have been using a simple self-written pure ruby implementation of IncenteevParameterHandler to deploy my parameters for quite a while.

Lately i removed --no-scripts and used environment variables with the original script. I was able to get the interactive input to work aswell.

We should discuss a solid solution for dealing with those parameter files - either create/use an external gem that provides parameter-handling in general (which would be my recommendation) ... or at least integrate IncenteevParameterHandler with capifony by default if possible as it is part of the symfony2 standard edition.

@nifr
nifr commented Nov 5, 2013

Those logfile-handling tasks like tailing should be moved out of the capifony/symfony/whateveryoucallit core aswell in my oppinion.

Testing the application should be moved to an external phpunit/testing gem, too.

Let's take a look into the great future of pain-free deployments that everybody can and will use ...

... where someone, somewhen will come up with a nice capistrano configurator

... where we can click together our modular tasks/recipes (capifony being one of them)

... of which each only provides the stuff we really need just at that moment

... or we have a really nice CLI ( <3 ncurses ) or symfony/console or ... that guides us safely through our deployment process

... a symfony2 bundle to deploy our application interactively from the web-profiler

... maybe even a nice repository for deployment recipes/tasks.

Efforts have been made towards all of these points in the past ... none of these projects really survived because the amount of work needed to put it all together was too much...

We can have all that ... but we need smaller, widely used and well tested modules first ... lets walk our first steps into the right direction with capifony and start decoupling.

@peterjmit
Contributor

ping @willdurand, as the maintainer would be good to hear what you think on all the above...

@willdurand
Collaborator

Yeah, too long didn't read yet. I'll take time to read everything and give my POV. Don't hesitate to add new ideas, we will see.

@nifr
nifr commented Nov 6, 2013

We need to split up this brainstorming into several feature collection + discussion pairs. Otherwise this issue is soon going to become confusing and won't encourage people to participate in the discussion due to it's overwelming number of comments.

@nifr
nifr commented Nov 6, 2013

@willdurand could you quickly add a v3 label to the issue tracker for a better overview?

@peterjmit
Contributor

@nifr We haven't made any decisions yet for what direction to take so I think splitting up the discussion may be a little premature

@nifr
nifr commented Nov 6, 2013

That's true but it would be nice to be able to tag feature proposals with v3 + proposal/request and have these separated. We can solve the decoupling decisions here but additional features for v3 should be taggable.

I have like 30+ things in the pipe and i'm pretty sure they will get lost in here ...

Now It's time to come up with some clear questions ...

@willdurand , @everzet we really need you to comment on a few things to get this thing going.

Who will be the core members and decision makers for the rewrite?
How will we face decisions in the future? [ public votings | internal votings ]

Do we drop Symfony1 support in the new version? [ yes / no ]
Do we drop the bin/vendors installation? [ yes / no ]
I say yes to both but we should get some more oppinions first.

Should we decouple composer operations into a separate gem? [ yes / no ]
I think composer is the most obvious candidate for decoupling ... but there are some more

Which features are the most important? [ => separate issue ]

We should aswell discuss a generic structure for the rewrite. coding standards, documentation, release process, testing frameworks...

@peterjmit
Contributor

@willdurand has already said that he will comment in due time, we have already agreed that dropping Symfony 1 support (and bin/vendors) is the path we will take.

I have also agreed to take the lead on this v3 rewrite - thats why I opened this PR in the first place!

Like you say, the separate gem idea is something that needs discussing - not only here but eventually with the Capistrano folks (because if it is the path we decide to take, that would be the best place for it to live).

@peterjmit
Contributor

@nifr [edited] I am removing my comment other than to say lets keep this friendly and on topic

@willdurand
Collaborator

Calm down folks!

First, keep commenting on what you want/wish/don't want. I'll take all suggestions and come up with a roadmap that will be the best compromise IMO. We will have to agree on every single point before working on the v3.

Also, symfony 1.x support will be dropped. Same thing for the bin/vendors thing.

Last but not the least, I told @peterjmit to work on the v3, and therefore he became the defacto lead developer.

I need new people to work on capifony. Just let me know what you want to do.

And, again, be nice together please.

@nifr
nifr commented Nov 7, 2013

Thanks for your statement @willdurand. That clears things up.

@peterjmit I dropped my comment aswell - sorry, didn't mean to be rude. Maybe we misunderstood each other a bit. I just wanted to push things forward a bit too quick maybe.

Let's focus and get this going. I'm willing to help wherever i can. I have a few suggestions for the general structure.

@peterjmit could you open an issue tracker in your repo or shall we go for the v3 tag here?

@willdurand
Collaborator

Great :)

By the way, I have several ideas for the v3. Basically, capifony v2 provides way too much features, it would be nice to drop as much features as we can, it will easier to maintain. For instance, Composer runs scripts that are useful to install assets, warm up cache, and so on. I don't think we need to keep such tasks in the v3. People use Composer and the script handlers provided by the Symfony standard edition most of the time. So let's rely on Composer. However, we might introduce some tasks in order to ease our life.

I like the database backup feature, but it is partially implemented. We will need to work on it at some point.

I introduced many optional settings in the v2, and I think it would be nice to do the same in the v3. Being able to set custom options while running Composer, PHP, or any other command is important IMO.

Oh, and we will have to focus on tests.

@nifr
nifr commented Nov 7, 2013

Settings
I think we should keep all settings/options in one place - something like configuration/defaults.rb.
In my opinion spreading all these defaults across multple files was a major flaw of v2. It was hard to find all possible settings/adjustments and not all of them were documented.

This would enable us to keep them together with a decent documentation for each option in that file. For doc-comments i suggest going for yard. It is mostly backward compatible with rdoc but provides a more complete featureset. Additionally http://rubydoc.info updates the yard documentation on every push.

New users could get a quick overview of all options and what's possible this way. What do you think?

@nifr
nifr commented Nov 7, 2013

composer & post-install/post-cmd hooks
While composer provides the ability to run tasks like dumping/installing assets and you can add shell commands directly in your composer.json - this does not cover all deployment situations.

I usually don't compile my assets on the production server for a simple reason. Depending on the frontend complexity you need a lot of dependencies on your production server for this one single task ( ruby, nodejs,minimizers, css preprocessors, image optimizers, ... ). Further there are situations where you don't have access to these on the production server and don't have the permissions to install them.

A workaround but not a clean solution would be adding the assets i.e. to the production branch of the repository.

Being able to compile / install the assets ( additionally in a configurable/temporary location when working with a headless repository ) before deployment would be very useful.

@nifr
nifr commented Nov 7, 2013

Capifony v2 task summary

57 (+1 default) tasks provided by capifony (symfony2)

:symfony:default
:symfony:logs:tail
:symfony:logs:tail_dev
:symfony:assets:update_version
:symfony:assets:install
:symfony:assetic:dump
:symfony:vendors:install
:symfony:vendors:reinstall
:symfony:vendors:upgrade
:symfony:bootstrap:build
:symfony:composer:get
:symfony:composer:install
:symfony:composer:update
:symfony:composer:dump_autoload
:symfony:composer:copy_vendors
:symfony:composer:dump_autoload_temp
:symfony:cache:clear
:symfony:cache:warmup
:symfony:project:clear_controllers
:database:dump:remote
:database:dump:local
:database:move:to_remote
:database:move:to_local
:deploy:set_permissions
:deploy:share_childs
:deploy:finalize_update
:deploy:cold
:deploy:test_all
:deploy:migrate
:deploy:drop
:symfony:doctrine:cache:clear_metadata
:symfony:doctrine:cache:clear_query
:symfony:doctrine:cache:clear_result
:symfony:doctrine:database:drop
:symfony:doctrine:database:create
:symfony:doctrine:schema:create
:symfony:doctrine:schema:update
:symfony:doctrine:schema:drop
:symfony:doctrine:load_fixtures
:symfony:doctrine:migrations:migrate
:symfony:doctrine:migrations:status
:symfony:doctrine:mongodb:schema:create
:symfony:doctrine:mongodb:schema:update
:symfony:doctrine:mongodb:schema:drop
:symfony:doctrine:mongodb:indexes:create
:symfony:doctrine:mongodb:indexes:drop
:symfony:doctrine:init:acl
:symfony:propel:database:create
:symfony:propel:database:drop
:symfony:propel:build:model
:symfony:propel:build:sql
:symfony:propel:build:sql_load
:symfony:propel:build:all_and_load
:symfony:propel:build:acl
:symfony:propel:build:acl_load
:deploy:web:enable
:deploy:web:disable
:shared:folder:download

proposal

29 commands execute/proxy symfony2 commands

:symfony:assets:install
:symfony:assetic:dump
:symfony:cache:clear
:symfony:cache:warmup
:symfony:doctrine:cache:clear_metadata
:symfony:doctrine:cache:clear_query
:symfony:doctrine:cache:clear_result
:symfony:doctrine:database:drop
:symfony:doctrine:database:create
:symfony:doctrine:schema:create
:symfony:doctrine:schema:update
:symfony:doctrine:schema:drop
:symfony:doctrine:load_fixtures
:symfony:doctrine:migrations:migrate
:symfony:doctrine:migrations:status
:symfony:doctrine:mongodb:schema:create
:symfony:doctrine:mongodb:schema:update
:symfony:doctrine:mongodb:schema:drop
:symfony:doctrine:mongodb:indexes:create
:symfony:doctrine:mongodb:indexes:drop
:symfony:doctrine:init:acl
:symfony:propel:database:create
:symfony:propel:database:drop
:symfony:propel:build:model
:symfony:propel:build:sql
:symfony:propel:build:sql_load
:symfony:propel:build:all_and_load
:symfony:propel:build:acl
:symfony:propel:build:acl_load

Should all be included using one helper function ( @peterjmit already did something like this in his PR )

We could introduce auto-registering all possible commands and their options provided by our application using the output of app/console list --raw and filter them with a white-/blacklist. Who needs propel/mongodb commands in cap -vT if he doesn't even have them present in his application.

What do you think about this?

3 deprecated tasks

:symfony:vendors:install
:symfony:vendors:reinstall
:symfony:vendors:upgrade

bye, bye ..

6 tasks composer integration

:symfony:composer:get
:symfony:composer:install
:symfony:composer:update
:symfony:composer:dump_autoload
:symfony:composer:copy_vendors
:symfony:composer:dump_autoload_temp

Should be moved to an external gem/plugin!

There are several things on my list for composer. Will be covered in a separate post.

4 tasks database management

:database:dump:remote
:database:dump:local
:database:move:to_remote
:database:move:to_local

Very practical but should be moved to an external gem/plugin.

I.e. getting the parameters from a local-install / environment variables needs improvement.

2 tasks for maintainance

:deploy:web:enable
:deploy:web:disable

Should be moved to an external gem/plugin!

1 task for shared folder download

:shared:folder:download

Should be moved to an external gem/plugin - something for generic remote file handling i.e. !

2 tasks tailing logfiles

:symfony:logs:tail
:symfony:logs:tail_dev

should be moved to an external gem/plugin - i.e. remote file handling ( see above ).

1 phpunit task

:deploy:test_all

[x] lacks check requirements
[x] lacks install if not present
[x] lacks specify path to phpunit
[x] lacks configuration options

should be moved to an external gem/plugin.

7 file/permission handling tasks

:symfony:project:clear_controllers
:deploy:set_permissions
:deploy:share_childs
:deploy:finalize_update
:deploy:cold deprecated
:deploy:migrate
:deploy:drop

These should use a well-defined file-handling gem/plugin that is maintained externally.

@nifr
nifr commented Nov 7, 2013

Configuration/Setup

improvement
It would be awesome to have some commonly needed templates ( i.e. single-server + local git-repository) provided by capifony. The template(s) should have their own files instead of being included in bin/capifony directly. erb is easy to use and implement here.

cap . has changed to cap setup in Capistrano3 - We should use capifony setup aswell.

feature addition
An interactive questionaire for a few options during setup would totally help new users.

We should introduce a few more flags for the setup command aswell:

capifony setup --no-interaction --template=single-server --scm=git --...

Capistrano 3 doesn't have the dependency to highline anymore.

While providing a class for configuration questions the old Capistrano::CLI.password_prompt() is missing but may need to be implemented by us for interactive configuration in the case of temporary passwords (ssh, scm).

We should encourage(force?) users not to store passwords in their deployment configurations.

What do you think?

@nifr
nifr commented Nov 7, 2013

coding standards & quality

We sould provide a .rubocop.yml and integrate rubocop with rake (link) + travis-ci to enforce coding standards for v3.

What about BDD / cucumber ?

Further monitor our code quality and test coverage with codeclimate and coveralls.io.

@peterjmit peterjmit Option to pass arguments to symfony:default task
Now symfony:cache:clear can invoke the symfony:default task
without duplicating the same logic for executing the command
directly
8972709
@peterjmit
Contributor

Tests
For testing I think we should be following the lead of the capistrano main repository. They have a integration suite using cucumber and a vagrant virtualbox to test deployments which I think would be useful for us.

Configuration
Capistrano already uses .erb templates for the cap install task. My hope was that capifony could override/hook into this and provide it's own templates through the same mechanism (i.e. to someone who is already familiar with capistrano, gem install capifony && cap install would be familiar rather than having a custom command).

Composer
I agree with @willdurand in that relying on the install scripts that are run by composer is an option - that is the approach I have taken thus far. Although I think that capifony should accomodate a user trying to

Assets
I am not convinced that an asset compilation feature that is useful to the majority of users (outside of assetic) would use and could just add another thing to maintain (that would be better handled by users themselves). I personally don't care for assetic and use Grunt for front-end build. This is certainly a biased opinion though.

Settings

I think we should keep all settings/options in one place - something like configuration/defaults.rb.

I originally implemented exactly that, and then I decided to split variables across different files - I couldn't decide which was best so am happy to have it either way!

DB & backups
I also often use the database backup feature but I think that it would almost certainly be useful as a separate gem (downloading a MySQL/Postgres backup is hardly specific to a Symfony or PHP project).

Testing (of deployed code)
This should definitely not be a concern of this project. This kind of thing should really be handled through CI etc, and anyone who really wants to run tests via capifony/capistrano should be doing it themselves.

Personally my main desire is to keep this as simple as possible and aim to prioritize to aiding a user of the Symfony standard edition in deploying their project. I also would like to aim to keep this layer on top of Capistrano as transparent as possible, so as to help us keep up to date with the main project - and be accessible to Capistrano users.

@peterjmit
Contributor

Someone beat me to it and has got a capistrano-composer gem up and running in the Capistrano organisation.

It doesnt work however so I have opened a pull request to fix it, I have an unpushed commit integrating this gem into my v3 branch - just waiting for the fix

@peterjmit peterjmit closed this Nov 7, 2013
@peterjmit peterjmit reopened this Nov 7, 2013
@peterjmit

I have move all config settings into one file as @nifr suggested - we probably want to reduce the number of configuration values anyways (there are still many).

The load:defaults tasks seems to be the proper way to load the settings in

@peterjmit
Contributor

The capistrano-composer gem does not provide a way to install the composer.phar executable as capifony previously did. When I wrote the composer.rake task I included it however I don't think it was the best approach. I think that ideally users would be managing their install of composer other than downloading it for each project - therefore I don't think capifony should take the responsibility for installing it as part of the core project (chef/puppet/ansible or the like should be managing it?).

For users who really want it installed as part of deployment we could provide the following cookbook entry

SSHKit.config.command_map[:composer] = "#{shared_path.join("composer.phar")}"

namespace :composer do
  task :install_executable do
    on roles fetch(:composer_roles) do
      next if test "[ -e #{shared_path.join("composer.phar")} ]"
      within shared_path do
        execute :curl, "-s", "https://getcomposer.org/installer", "|", :php
      end
    end
  end
end

namespace :deploy do
  before :starting, 'composer:install_executable'
end

This piece of code only installs composer if it has not already been installed, and it installs it to the shared path before deployment starts so it can be re-used across runs. Finally it uses the SSHKit command mapping to provide the path to the composer executable (without that map it would be running /usr/bin/env composer as a default).

Check out SSHKit and some examples if you haven't already, it is a nice little library.

@peterjmit
Contributor

Capifony has had a lot of boolean settings in it's configuration that added flags to commands, or removed them etc. I think that this is a little unwieldy and is a un-necessary abstraction. If a user is running a symfony command they should/will know exactly which flags they want to run it with.

Hence the config variable symfony_console_flags and removal of variables like interactive_mode & symfony_debug in c019759

Also the php_bin setting has been removed in favor of being able to command map it with SSHKit e.g.

# deploy.rb
SSHKit.config.command_map[:php] = "/some/custom/path/to/php"
peterjmit added some commits Nov 7, 2013
@peterjmit peterjmit Add dependency on capistrano-composer
Until capistrano/composer#5 is closed, .gemfile
should point at github.com/peterjmit/composer for the source
3223646
@peterjmit peterjmit Using Capistrano::DSL::invoke over Rake::Task 9ffedf7
@peterjmit peterjmit Added methods for accessing common symfony paths
Mimics release_path and shared_path in Capistrano::DSL::Paths
876acd4
@peterjmit peterjmit referenced this pull request in capistrano/composer Nov 8, 2013
Closed

Configurable environment variables for composer:install #6

@peterjmit peterjmit referenced this pull request in capistrano/composer Nov 8, 2013
Merged

Add install_executable, dump_autoload and self_update tasks #7

@peterjmit
Contributor

I have taken @nifr proposal of a file permissions gem/module and implemented it peterjmit/capistrano-file-permissions.

It could be an option rather than worrying about it here. (see c88f674)

@ruudk
Contributor
ruudk commented Nov 15, 2013

I currently use a conditional.rb file that has the following checks:

  • Check if the commits contain any migration, if so, auto start migrations
  • If resources are changed assetic:install is triggered. If not, old assets are copied to speed things up

Would be great to have this in core.

@willdurand
Collaborator

Hi there! I have gathered all your feedback, and will try to come up with something that should look like a roadmap by the end of the month. Not sure I can do something else before unfortunately..

@1ed
1ed commented Jan 6, 2014

@willdurand any update on this... do you have a roadmap yet? Any chance of this will be merged soon?

@peterjmit
Contributor

I have left this alone in absence of comment from @willdurand (who I am sure is very busy). I am happy to pick this back up if/when comment is received.

@nifr
nifr commented Jan 7, 2014

I'm still following this issue aswell and waiting for @willdurand 's starting shot. :)

@thorsten
thorsten commented Feb 1, 2014

Any feedbak on Capistrano 3 and Capifony?

@nifr
nifr commented Feb 2, 2014

There has still been no feedback / proposed roadmap from @willdurand in 3 months now.

He has recently been actively maintaining wildurand/negotiation and even pushed a new commit to capifony itself 2 days ago.

... while we're still waiting for feedback from him or @everzet here.

Sadly both of them don't seem to notice (or care about) new comments to this thread anymore.
Looking at their public activity and the fact that we pinged them over and over again ...

https://github.com/everzet?tab=activity
https://github.com/willdurand?tab=activity

... i'm not quite sure anymore if we'll ever get the chance to collaborate on a capistrano v3 version of capifony over here. Not to mention active maintenance afterwards. That's somewhat disappointing as 4 months have passed since this issue was created.

@peterjmit and i both have working alpha-state versions of a symfony2 deployment plugin for capistrano v3 that (if merged somehow and improved together with others) many people could benefit from.

The main reason for starting this thread was Peter's (and my) vision that this repository and the popular name capifony paired with @willdurand's and @everzet's experience with capifony would make it easier for the community to find this plugin and possibly contribute to it. We wanted to make use of existing infrastructure (i.e. capifony is already mentioned in the symfony docs) and not re-invent the wheel.

Now we're somewhat stuck. I would suggest that we'll try to contact @willdurand an @everzet once more ... and if we don't still don't get a response / roadmap within a reasonable timeframe (of let's say two weeks) we should consider taking a different approach ...

Be it asking @leehambley to create a capistrano/symfony repository or inventing a new fictive brand for this new plugin ...

The coolest thing would still be to hear from @everzet or @willdurand ... even if they only gave green light in terms of "we don't have the time to maintain a v3 branch but we're not willing to hand out permissions for this repo to someone else"

What do you think Peter?

@willdurand
Collaborator

Well, I am following and still maintaing capifony. Writing a roadmap is not easy as none of us knows all use cases. While what we have right now here sounds good, I'd like to not miss important stuff.

And yeah, you noticed I managed quite a lot of other projects, thank you for your support... Please go read my last blog post. At some point I need to prioritize tasks, capifony works, hence the low priority.

❤️

@thorsten
thorsten commented Feb 3, 2014

Thanks for the feedback, @willdurand

@willdurand
Collaborator

I put "capifony" on top of my todolist if it can help.

@danez
Contributor
danez commented Feb 7, 2014

I know that sometimes priorities shift due to changes in life or other projects taking more time. And as capifony is open source it is probably also build and maintained in the contributors free time.

But as this project is really popular and probably has a lot of users, I think it is sad that the project has only little progress. As @peterjmit and @nifr have done a lot on v3 and seem really to understand what capifony is doing under the hood, wouldn't it make sense to have on of them or both as additional maintainer on the project? (Given that they would want to do this.)
Really looking forward to see some progress in capifony v3. @willdurand

@nifr
nifr commented Feb 9, 2014

Thanks for the feedback and life-sign @willdurand 👍

Yes, I happened to read your blog-post quite a while ago and i'm the last person on earth that doesn't understand your situation ... seriously!

We all understand that you're currently busy with other (awesome) things and that you've got a long list of stuff with higher priorities. Personally i'm more than grateful for all the nice, high-quality stuff you push out to the community ... and to me you're a miracle in terms of productivity.

My personal time-frame for open-source contributions is limited, too. It's just been somewhat frustrating that you said you'd come up with a timetable in a week or so ... and we - as the ones really wanting to help out, parring the ground - didn't get a response for 3 months afterwards.

The thing is ... our hands are tied right now. We need something to start with - some infrastructure that we can work with ... to get this v3 version going ! Be it a v3 tag for collecting more ideas, splitting feature discussions to start with... or at best a v3 branch that we can push some code to - if we want to be able to contribute to capifony v3 somehow.

There are obvious benefits in creating a new capifony version on the shoulders of capistrano v3 from scratch together. While capifony is working as is - i'm sorry to say that - looking back at my personal experience in setting up my first automated deployment with it back then ... i wouldn't consider capifony a completely mature project. The public interest is obvious though.

A lot could be improved in a v3 version - better, mandatory tests for features, project-structure, documentation, ... and we're here to help ! But if we continue like this there will be no capifony v3 in 2020 ...

This repository is - not only due to its popularity ... with no simple symfony2 deployment alternatives around - THE place for building something rock-solid
that many people will benefit from.

From my personal experience even 3/4 agencies are still not making use of automated deployments due to a lack of knowledge ( and fear of diving into another programming language like ruby ) ... and as long as we don't have ssh-agent support around in PHP in simple library like Seclib - without the need of installing that old-fashioned SSH2 extension... there will be nothing like capistrano in PHP. And i'm not the only person thinking like that,

@willdurand ... take your time ... think about how you can enable us to kick this off without you getting overwhelmed by a "new", additional project that needs maintainance, guidance ... and tell us what we can do to assist.

Thanks in advance :)

@peterjmit
Contributor

So due to the 5 month wait, and some personal/work related requirements I have decided to release https://github.com/capistrano/symfony.

It is going to remain very simple so there is scope to have capifony build upon that and perhaps provide extra "sugar" for those wanting more functionality, or more out of the box config for those less comfortable with writing ruby.

I will close this PR shortly unless anyone has any objections.

@nifr
nifr commented Feb 28, 2014

RIP capifony v3 🔨

I'm cool with that as I'm quite sure there will be no capifony v3 ... ever. We've waited long enough.

Sadly we didn't get the chance to collaborate @peterjmit and @willdurand . I would've really appreciated that.

I had a different vision for a new start ... team-up with you and probably a few more guys. Build a group that would collectively take decisions, then collaboratively prepare the infrastructure (homepage,docs, ...) and create a release plan ... to finally release a solid application that fits some enterprise needs and is worth spreading the word at the point of it's initial release.

I offered a hangout , was willing to contribute some code and ideas for the generic structure of the new project to prevent releasing just another highly immature project to the public.

At least by now we just have another one-man-show going on here. This thread is a wonderful example where this is leading.

The new capistrano/symfony is a lib with 10 files and there's not a single test.

There's no CI, no codestyle rules, no contribution guidelines, no examples that would show new users how to install and configure it to quickly deploy their first application - there's basically nothing that tries to ensure a decent level of quality by now.

I truly hope the new project matures with time, gets some attention and can at some point replace capifony but i have strong doubts about that ... anyways good luck with it Pete.

I'll focus on other things now.

@peterjmit
Contributor

@nifr Weird attitude, it is under the Capistrano organisation (and so gains their community and input/oversight) and it is v0.1.0. It is just a start and if you want to contribute you are more then welcome.

I figured it was better to do something rather than nothing and I was fed up of having to custom install the capifony gem from my v3 branch.

@willdurand
Collaborator

Well. We can still start v3 from there, no need to close this PR.

@nifr is right. I would prefer to give you, @peterjmit, commit access to this repo rather than having another project, untested, and quite unknown.

@KingCrunch
Contributor

@willdurand

I would prefer to give you, @peterjmit, commit access to this repo

Is it me, or isn't that something we are waiting for quite a while? 😕

@willdurand
Collaborator

This is not how things work. I took the lead of capifony because I asked @everzet in person, explaining what I planned to do, and so on.

Here, this is not exactly the same thing. I thought I had enough time to prepare the v3, but it seems that you are really in a rush. Hence the proposal here..

@leehambley

Hey, let's try and keep this civil. FOSS maintainer ship is a burden, anyone who's spent weeks waiting for me knows how much pressure I can be under. As a maintainer it's painful to know you are disappointing people, but have to choose that, or burnout.

A fork doesn't need to mean the end to collaboration, and I hope that people will all rally behind _the best experience for Symphony users_, I can't say who that will be, and my supporting any fork/project under capistrano/* doesn't equate to endorsement, just facilitation.

For whatever it's worth, I think that the project exists at all is great, and regarding tests, perhaps the work I was starting in https://github.com/capistrano/packer might constitute a good place to start integration testing/tutorials/etc, which is how I envisioned that being used.

@peterjmit
Contributor

I am honestly happy to do whatever people think is best - I just want to do something, and people have been asking me what the status of this PR is semi-regularly. Unfortunately I have received no communication or indication on next steps for this PR from @willdurand (I have reached out both here, and on twitter) making it very difficult to know whether I should continue to work on this.

From what I can see a lot of work has gone into building a test environment for capistrano v3, and I would like to benefit from that with the Symfony integration.

I think this repository suffers from being monolithic which I feel must have been a factor in the lack of progression here. There is also lot of functionality within this project that I feel could benefit both non Symfony, and non PHP projects (database tasks, backup tasks, etc).

I am sorry if this appears to be an move towards fragmentation, that is not my intention My hope was that under capistrano/* the project could gain from that community (in addition to everyone contributing here).

@peterjmit peterjmit closed this Mar 31, 2014
@armetiz
armetiz commented Apr 1, 2014

Hi there,
Do you heard about : capistrano-symfony ?

Regards,

@willdurand
Collaborator

@armetiz there is capistrano/symfony that is more or less capifony v3.

@Shine-neko

@willdurand therefore Capifony (this repository) is death ?

@willdurand
Collaborator

No. It is still maintained.

@Shine-neko

But not with capistrano v3 ?

@willdurand
Collaborator

Exactly.

@webdevilopers

👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment