[Flow] TYPO3 Surf questions

[Christian Loock]

Hey,

Am 29.10.2014 um 22:11 schrieb Mark Kuiphuis:
> Thanks guys....
>
> Might need to some work on this then :-) But I wouldn't be where I am 
> currently at without both your help, so really appreciated :-)
>
I know surf can be somewhat confusing, since the documentation isn't all 
that good. I took me quite a while to get into it by experimenting 
around quite a bit. But once you get it running, the deployment works 
really good. It also not too hard to use surf to deploy other 
applications. We is it to deploy our Oxid Shop aswell, which shows how 
flexible surf is. I really love it and am glad I could help :)

> So if I understand you correctly, on every deploy you are downloading 
> TYPO3.Flow, TYPO3.Fluid, Libraries like Doctrine, Yaml, etc. etc.?
>
As mentioned before, composer caches libraries, so once they are 
downloaded, composer will prefer the cached version, unless the 
requested version changed.


> Cheers, Mark
>
> P.S. Might need to work on doctrine:migrate a bit more because up 
> until now we have only used doctrine:update :( Thanks for this tip....
>
> On 29/10/2014 6:20 pm, Christian Loock wrote:
>> Just to add to this:
>>
>> Be aware that using doctrine:update, even if it might seem very
>> convient, might screw up your possibilites to generate migrations with
>> doctrine:migrationgenerate. We used to use doctrine:update on our loca
>> working copies aswell, untill we tried to deploy our application the
>> first time to our production environment, and realized that our
>> migrations were broken, since they were missing stuff. Since then, we
>> made it a convention to always use doctrine:migrate and never update the
>> database directly with doctrine:update. This adds a little step, but
>> makes your migrations safe and tight.
>>
>> Also note, that composer has a cache, that will cache repositories it
>> checks out, for later use. So as long as you have you composer.lock
>> versioned, it should only download the repos at the first time you
>> deploy, and then take them straight from the cache, which is very quick.
>>
>> Cheers
>>
>>
>> Am 29.10.2014 um 09:09 schrieb Beat Guggisberg:
>>> Hey Mark
>>>
>>> If you copied the Database with all Data in it, then it should have
>>> also copied the Migrations Table. So without a codechange there should
>>> not have been any migration nessessary.
>>>
>>> On a Development system you should have no problem just to just clear
>>> your database and make a migration to come to the correct Databasae
>>> structure. To test your new things that change the database you can
>>> update manually with doctrine:update. Never do that on a production
>>> server, because it destroys future migrations.
>>>
>>> To create the migrations you need on the production server, clear the
>>> DB on the testserver, do a doctrine:migrate and then a
>>> doctrine:migrationgenerate. Now you have a file with all the DB
>>> changes in it. You can split up that file for your different packages.
>>>
>>> For your problem with the downloads, i have created local copies of
>>> all nessessary Git repositorys. You can do that with "git clone
>>> --mirror", to update them use "git remote update".
>>>
>>> Now you have to add them as repository in your json.
>>>
>>> Kind Regards
>>> Beat
>>>
>>>
>>> Am Mittwoch, 29. Oktober 2014 01:54 CET, Mark Kuiphuis
>>> <mark at capesso.com.au> schrieb:
>>>   Thanks Christian and Beat :-)
>>>
>>> Since this is all still very new to me, I wanted to test things
>>> thoroughly on a local server before putting it to use on a Live
>>> Production Server.
>>>
>>> I therefore made a copy of my development database instead of creating
>>> an empty database (which I did refer to by the way in the Settings.yaml
>>> in both Production and Development Contexts).
>>>
>>> It turned out that, because there was already a database (with 
>>> tables of
>>> my packages and the TYPO3.Party tables) it could not rename the
>>> party_abstractparty to typo3_party_domain_model_abstractparty, because
>>> that table already existed.....
>>>
>>> I now need to find a way to move a lot of folders from the releases
>>> folder to the "shared" folder and symlink them, because I don't want to
>>> download TYPO3.Flow, TYPO3.Fluid, and all libraries when I made a 
>>> change
>>> to one of my own packages and want to deploy these changes.
>>>
>>> And while my own packages have been downloaded succesfully from our own
>>> git server, it did not create the necessary tables upon first 
>>> run....but
>>> that could maybe be due to the lack of a migration script....
>>> (not something that I want to do upon each deploy anyway as it should
>>> reuse existing tables and modify them instead of creating (for example
>>> party_abstractparty which then should be renamed again to
>>> typo3_party_domain_model_abstractparty)...
>>>
>>> Cheers, Mark
>>>
>>> On 27/10/2014 4:47 pm, Christian Loock wrote:
>>>> Hey,
>>>>
>>>> you are probably just missing the Config for the Production Context
>>>> in you
>>>> base repo. Surf will automatically call everything in Production
>>>> context,
>>>> so you need your Configuration/Production/Settings.yaml to reflect to
>>>> your
>>>> actual production database.
>>>>
>>>> Also you are right, Surf will automatically create the whole folder
>>>> structur for you. Make sure your vhost on your production node 
>>>> points to
>>>> %projectdir%/releases/current/Web where %projectdir%= the directory 
>>>> you
>>>> deploy to.
>>>>
>>>> 2014-10-27 3:37 GMT+01:00 Mark Kuiphuis <mark at capesso.com.au>:
>>>>
>>>>> Hi all,
>>>>>
>>>>> Finally found the time to start digging again in regards to 
>>>>> TYPO3.Surf
>>>>>
>>>>> I am experiencing the following problem and although I do see the 
>>>>> error
>>>>> message "No datrabase selected", I have no idea how to solve it...
>>>>>
>>>>> staging (Vendor.Package) typo3.surf:typo3:flow:symlinkdata
>>>>> staging (Vendor.Package) typo3.surf:typo3:flow:symlinkconfiguration
>>>>> staging (Vendor.Package) typo3.surf:typo3:flow:copyconfiguration
>>>>> Stage migrate
>>>>> staging (Vendor.Package) typo3.surf:typo3:flow:migrate
>>>>> Uncaught Exception
>>>>> An exception occurred while executing 'SHOW FULL TABLES WHERE
>>>>> Table_type
>>>>> = 'BASE TABLE'':
>>>>>
>>>>> SQLSTATE[3D000]: Invalid catalog name: 1046 No database selected
> _______________________________________________
> Flow mailing list
> Flow at lists.typo3.org
> http://lists.typo3.org/cgi-bin/mailman/listinfo/flow