Deployer executes a set of commands on the target server to build your project and enable the newly built version. A typical deployment process with Deployer involves SSHing into the target machine, where it performs a Git checkout of the project, installs dependencies via Composer, runs build commands, and possibly triggers some database migrations. When everything is successful, it will symlink the webroot to the new release.

On some servers, however, there are limitations that make this process unfeasible. For instance, you can’t install Composer, Git isn’t available, the CLI PHP version is different and can’t be changed, or certain asset-building processes aren’t possible because Node.js isn’t installed. This is often the case with shared hosting.

The strategy, therefore, is to build the project locally and upload it to the target machine.
In Deployer 6 there was a buildIn mechanism for building your project on the local host.
However with Deployer version 7 this has been removed and building your project locally has become a bit more fiddly.

With Deployer 6 you could just use the local() method on a task and set the deploy_path to a local dir.

task('build', function () {
    set('deploy_path', __DIR__ . '/.build');
    invoke('deploy:prepare');
    invoke('deploy:release');
    invoke('deploy:update_code');
    invoke('deploy:vendors');
    invoke('deploy:clear_paths');
    invoke('deploy:symlink');
})->local();

Then you could combine this with an upload task in a deploy task an you are done.

task('upload', function () {
     upload(__DIR__ . "/.build/current/", '{{release_path}}', ['--links']);
 });

 task('deploy', [
     'build',
     'upload',
     'cleanup',
     'success'
 ]);

See here for the docs of Deployer 6:
https://deployer.org/docs/6.x/advanced/deploy-strategies#build-server

Since Deployer 7, however, the local() method was removed. Instead, there is now a localhost() method, which defines a host for local builds. Additionally, you still need to define the remote host as the target destination for the upload.
However, you cannot specify a single task to run on a specific host, and therefore you cannot combine tasks for localhost and the remote host within a single task.

To build the project, we now need two separate tasks.
I managed to make it work with two tasks and two hosts: one for local build and one that takes the fresh local build and uploads it to the remote host.

localhost('local')->set('deploy_path', __DIR__ . '/.build');

host('remote')
    ->setHostname('server-host.com')
    ->set('remote_user', 'user')
    ->set('deploy_path', '/www/blog')
    ->set('http_user', 'user');
....

task('build', function () {
    // build it
})->once();

task('upload', function () {
    upload(__DIR__ . "/.build/current/", '{{deploy_path}}', ['--links']);
});

Then I simply run two separate commands: one for building on the local host and one for uploading to the remote host.

vendor/bin/dep build local
vendor/bin/dep upload remote

Not as convenient as previously but it works. :)

See this issue for context: https://github.com/deployphp/deployer/issues/2838

So i have this uncritical smaller API app where the hosting has git, ssh access and i am in full control and i decided too keep it simple.

For deploy i login via ssh and make a git pull too fetch the code.
Now we need to make a composer install, if the composer.lock has changes to fetch all php dependencies.
Therefor i found a handy bash script, tweaked it a bit and installed it as post-merge git hook.

Install the hook:

cd project
nano .git/hooks/post-merge #paste & edit the script
chmod 775 .git/hooks/post-merge 

What it does?
After all code from the git pull is merged into the working tree, the hook checks if the composer.lock has changed. If so it will run a composer install.
Note that it runs with –no-dev since we are on production and dont need f.e. phpunit there.

I know you know, but let it be said again: run composer install not composer update, as you never should run composer update on production, read why here.

So here is the bash:

#/usr/bin/env bash
# MIT © Sindre Sorhus - sindresorhus.com
# forked by Gianluca Guarini
# phponly by Ivo Bathke ;)
 
changed_files="$(git diff-tree -r --name-only --no-commit-id ORIG_HEAD HEAD)"
 
check_run() {
  echo "$changed_files" | grep --quiet "$1" && eval "$2"
}
 
# `composer install` if the `composer.lock` file gets changed
# to update all the php dependencies
check_run composer.lock "composer install --no-dev"

I forked it from here, that forked from there.

The twig-extension repository is usually fetched by calling

$ bin/vendor install

into your project´s ./vendor directory (because it is part of the ./deps file of each symfony 2 standard edition).

After installing the required vendor files, register the namespace fallback in your autoload.php (if you use the one delivered with Symfony 2 Standard, this should already have been done for you):

use Symfony\Component\ClassLoader\UniversalClassLoader;
use Doctrine\Common\Annotations\AnnotationRegistry;

$loader = new UniversalClassLoader();
$loader->registerNamespaces(array(
    'Symfony'          => array(__DIR__.'/../vendor/symfony/src', __DIR__.'/../vendor/bundles'),
    // ...
));

$loader->registerPrefixes(array(
    'Twig_Extensions_' => __DIR__.'/../vendor/twig-extensions/lib',
    'Twig_'            => __DIR__.'/../vendor/twig/lib',
));

Remember that twig extensions are always registered as tagged services, but it is not always desirable to register a twig extension like e.g. the Debug-Extension as a regular service globally. We could do so by adding the service definition to the services.xml-file in one of our bundles. But due to the special purpose of the debug extension, we will choose a different, more “project-wide-configuration”-way.

Luckily, Symfony provides means to dynamically load services “on demand” and depending on the current environment.

Add the following lines to your app/config/config_dev.yml:

services:
    debug.twig.extension:
        class: Twig_Extensions_Extension_Debug
        tags: [{ name: 'twig.extension' }]

The “services”-configuration option may be utilized to register any class as a DIC managed service, for each project and independent from your bundle configuration (But remember that “regular” service definition configuration should usually happen in your bundle´s configuration files, otherwise you will not able to distribute your bundles because of missing or broken dependencies).

For twig extensions that should only be loaded for special purposes (like our DEBUG-function which is only needed in development environments), config_dev.yml is the perfect place to register them.

Note the “tags”-configuration which marks the service as a twig extension. Now, let´s create a demo twig-template and try the {% debug %} function:

{% extends "NerdpressDemoBundle::layout.html.twig" %}
{% debug %}

That will do. Open the page in your favorite webbrower (after defining a route, a controller and other stuff i won´t mention here) and admire the debug output. Note that the output will be much more nicer if you have had installed a native php debug extension like e.g. XDebug.

In this scenario development is done on two local machines while products and pages beeing already edited on the “Live”-Web-Server.
Git is used for version control and deployment. Also FTP SSH.

Magento is quite nice when it comes to deployment, as most config stuff is stored in XML files.
Those files are kept locally and ignored from version control.

So this is what my .gitignore looks like:

#cache, sessions, logs
/var/cache/*
/var/session/*
/var/locks/*
/var/report/*
/var/log/*
#media folder - images etc...
/media/*

#local config files
/app/etc/local.xml
.htaccess

#database dump
/database.sql

So i got a copy of the repository in each environment with a local .htaccess and local.xml file.

Theres a few things stored in DB by magento, though.
The most obvious is the “web/secure/base_url” and “web/unsecure/base_url” which both reside in the “core_config_data” table.
Those have to be set to the name of the host you’re working on.

This can be done with a shell script like this:

#create a dupm of the live DB on the server
ssh user@server.com 'mysqldump -u[username] -p[password] > ~/db_dump.sql'

#copy DB dump to local machine
scp user@server.com:~/db_dump.sql ./database.sql

#import SQL
mysql -u[local_mysql_user] -p[local_mysql_pw] [local_db_name] < ./database.sql

#update config settings in the DB
mysql -u[local_mysql_user] -p[local_mysql_pw] [local_db_name]<UPDATE
core_config_data
SET value='http://local.server.com/'
WHERE value ='http://server.com';
EOFMYSQL

This way all CMS and products  can be edited on the server, while the local machines can be easily synched.
For me this works fine, as we are working only in the file system in the local environment.
In case you can’t use the online Server as “database master” this might be not that simple.

As we most likely don’t want the whole /media folder under version control we might want to have another shell script to copy the media files to the local machine (via SCP in this case):

#remove local media folder
rm -rf ./media/*
#fetch media files
scp -r ssh_user@server.com:~/magento_folder/media/* ./media

I guess this could be done more efficiently with maybe ant or something.
But for the moment this works fine for me.

So now i can update my local environment with one line on the console:

git pull; sh sync_db.sh; sh sync_media.sh

Nun denn, direkt mal probieren, der Post hier beschreibt schon ziemlich gut was und wie man da was machen kann.

Ich benutze noch ant 1.8.0, also machen wir was uns vorgeschlagen wird:

All features of the build script require Ant version 1.8.2. Please upgrade to 1.8.2 or remove all instances of ‘overwrite=no’ (and this fail task) from the build script to continue

Also alle overwrite Attribute raus und den Test Task rausnehmen:
Den Testtask rausnehmen:

 <fail message="All features of the build script require Ant version 1.8.2. Please upgrade to 1.8.2 or remove all instances of 'overwrite=no' (and this fail task) from the build script to continue">
        <condition>
            <not>
                <contains string="${ant.version}" substring="1.8.2"/>
            </not>
        </condition>
 </fail>

Dann probieren:

cd build
ant

Und funktioniert: in publish liegt jetzt das optimierte Web Projekt.

Danach noch die buffer folder leeren, ist nicht unbedingt nötig aber macht Spaß :)

ant clean

Um die Bilder Optimierung anzuschalten, muss ich noch die libs dafür nach installieren:

sudo apt-get install libjpeg-progs optipng

Kleiner Tip noch:
Nutzt man zusätzliche javascript libs, die nicht konkateniert werden sollen, sollte man die nicht zwischen die comments schreiben.
Diese hier:

 <!-- scripts concatenated and minified via ant build script-->
 <!-- end scripts-->

Und um es auf die Spitze zu treiben lassen wir mal den vollen minify laufen:

ant minify

Der komprimiert zusätzlich noch das Markup.

Aufräumen:

ant clean

Nun noch den publish folder uploaden:
Ich will ja FTP via ant benutzen also vorher die Abhängigkeiten davon installieren, siehe hier in einem alten Post von mir.
Außerdem muss man noch die FTP properties angeben, das passiert in config/project.properties:

 #FTP deploy
 tool.ftp.host = host
 tool.ftp.user = user
 tool.ftp.password = password
 tool.ftp.remotedir = httpdocs

Holt man sich die boilerplate direkt von github, ist da eine Neuerung drin, welche erlaubt den Build zu erweitern, indem man eine project.xml anlegt und darin seine eigenen targets anlegen kann.
Benutzt man die letzte stable version muss man den task direkt in die build.xml schreiben.

Der FTP task ist ganz simpel ohne Spirenzien:

<target name="ftpupload" description="uploads the publish folder to your web space via ftp">
	<ftp server="${tool.ftp.host}" userid="${tool.ftp.user}" password="${tool.ftp.password}" timediffauto="false" remotedir="${tool.ftp.remotedir}" action="send" verbose="yes" passive="yes" depends="yes">
            <fileset dir="${dir.publish}">
            </fileset>
        </ftp>
</target>

Dann mal uploaden:

ant ftpupload

Komplett ist das dann so:

 ant minify
 ant ftpupload
 ant clean

The script has two parameters:
– the folder to clone the whole thing into
– the branch/tag to checkout afterwards

# install silverstripe + common modules from github
# usage sh install_silverstripe.sh <folder_name> <tag/branch>
# examples:
# sh install_silverstripe.sh some_folder tags/2.4.5
# sh install_silverstripe.sh some_folder master

As Silverstripe itself is split up in 3 repositories
(the installer/base folder, the cms and the sapphire framework itself)
we fetch the base folder first:

#set up project base folder
git clone git@github.com:silverstripe/silverstripe-installer.git $1
cd $1
git checkout $2

Get the cms

#setup cms
git clone git@github.com:silverstripe/silverstripe-cms.git cms
cd cms
git checkout $2
cd ..

Get sapphire …

#setup framework
git clone git@github.com:silverstripe/sapphire.git sapphire
cd sapphire
git checkout $2
cd ..

Setup some permissions for the web installer.

#set permissions for install
chmod 0777 assets assets/*
chmod 0666 .htaccess mysite/_config.php assets/*/*

Fetch the blackcandy theme from a fourth repository.
Backup the tutorial theme in case we need it.

#install blackcandy theme
mv themes/tutorial ./
rm -rf themes
git clone https://github.com/silverstripe-themes/silverstripe-blackcandy.git themes
cd themes
git checkout $2
cd ..
mv tutorial themes

Install some modules

# install common modules
git clone https://github.com/unclecheese/Uploadify.git uploadify
git clone https://github.com/unclecheese/DataObjectManager.git dataobject_manager
git clone https://github.com/silverstripe/silverstripe-userforms.git userforms

iIput the script on github
…in case you might wanna use it or add something i’ve missed.

Then go for ant and its ftp task!

Install it on ubuntu like so (given you have ant and java already):

cd ~
wget http://apache.openmirror.de//commons/net/binaries/commons-net-1.4.1.tar.gz
tar -zxvf commons-net-1.4.1.tar.gz
sudo cp commons-net-1.4.1/commons-net-1.4.1.jar /usr/share/ant/lib
rm -rf commons-net-1.4.1
rm -rf commons-net-1.4.1.tar.gz

wget http://archive.apache.org/dist/jakarta/oro/jakarta-oro-current.tar.gz
tar -zxvf jakarta-oro-current.tar.gz
sudo cp jakarta-oro-2.0.8/jakarta-oro-2.0.8.jar /usr/share/ant/lib
rm -rf jakarta-oro-2.0.8
rm -rf jakarta-oro-current.tar.gz

Butz!
Now make your self an build.xml file in your projects root and do:

cd myproject
ant

Wahnsinn!

Ich benutze ja ganz gerne unfuddle für Projekte mit closed source.
Dort kann man nämlich mit dem free Account, anders wie bei github, private repositories erstellen.

Nun hatte ich aber neulich plötzlich einen Auth Fehler und konnte mich mit meinem key nicht mehr connecten:

ERROR:gitosis.serve.main:Repository read access denied
fatal: The remote end hung up unexpectedly

Ich war mir keiner schuld bewußt.

Nachdem ich meinen key gelöscht bei unfuddle hatte und neu anlegen wollte, kam dann die Fehlermeldung:

This public key has already been taken by another user.
If you have multiple accounts, you must use a different public key for each account.

Des Rätsels Löung war dann hier zu finden.

Kurz: ich hatte meinen key noch einem anderen Projekt zugeteilt, wo ich contribute, allerdings mit einem anderen Account.
Also zweiten key angelegt, bei unfuddle eingetragen, über ssh config einen switch eingetragen und schon klappts

Natürlich spricht nichts dagegen, das Script als Vorlage für seinen eigenen genererate-bootstrap-code zu modifizieren.

Die Aufgabe ist mit dem yuicompressor alle css files einzeln zu komprimieren.
Concatenation lasse ich weg.
Wir haben zur Auswahl 2 x mal als ant deploy und einmal die gute alte shell.

Das yuicompressor jar ist “installiert” und liegt hier:

/usr/share/ant/lib/yuicompressor.jar

Und es kann losgehen:

1. ant via apply task

Ein Property (im externen property file) für das jar:

yuicompressor=/usr/share/ant/lib/yuicompressor.jar

Und nun der task:

<target name="minifyCSS">
		<apply executable="java" parallel="false" verbose="true" dest="${buildir}/project/${updateChannelTemp}/">
			<fileset dir="${updateChannelTemp}/${SvnExportDir}/scripts/" includes="*.css" excludes="*.min.css"/>
			<arg line="-jar"/>
			<arg path="${yuicompressor}"/>
			<arg line="-v"/>
			<arg line="--charset latin1"/>
			<srcfile />
			<arg line="-o"/>
			<mapper type="glob" from="*.css" to="*.css"/>
			<targetfile/>
		</apply>
		<move todir="${buildir}/project/${updateChannelTemp}/${SvnExportDir}/scripts/" overwrite="true">
			<fileset dir="${buildir}/project/${updateChannelTemp}/" includes="*.css" />
		</move>
</target>

2. ant via yui-compressor task

Dazu brauch es noch ein paar Vorbereitungen:

Hierzu muss das Task noch “installiert” werden, ich packs mal zu den anderen jars und dazu ein Property:

yuicompressortask=/usr/share/ant/lib/yui-compressor-task.jar

Weiterhin den Ant ClassPath:

<path id="project.classpath">
		[...]
<pathelement location="${yuicompressortask}" />
		<pathelement location="${yuicompressor}" />
</path>

Den Task definieren:

<taskdef name="yui-compressor" classname="net.noha.tools.ant.yuicompressor.tasks.YuiCompressorTask">

und das eigentliche Target:

<target name="minifyCSS2">
<mkdir dir="${updateChannelTemp}/${SvnExportDir}/scripts/css/"/>
<yui-compressor 
    warn="false" 
    munge="true" 
    cssSuffix=".css"
    jsSuffix=".js" 
    preserveallsemicolons="false" 
    fromdir="${updateChannelTemp}/${SvnExportDir}/scripts/" 
    todir="${updateChannelTemp}/${SvnExportDir}/scripts/css/">
  <include name="*.css" />
</yui-compressor>
<move todir="${updateChannelTemp}/${SvnExportDir}/scripts/" overwrite="true">
		<fileset dir="${updateChannelTemp}/${SvnExportDir}/scripts/css/" includes="*.css" />
</move>
<delete dir="${updateChannelTemp}/${SvnExportDir}/scripts/css/" />
</target>

3. via shell

java -jar /usr/share/ant/lib/yuicompressor.jar --type -v css < /home/builds/project/css/*.css > /home/builds/project/css/*.css

Fazit:
Ich hasse liebe ant.
Achtung: keine Gewähr, dass das die snippets funktionieren, weil ziemlich aus dem Kontext gerissen.
Ich wollte nur mal verdeutlichen was für ein overhead ant manchmal erzeugt.
Ich benutze es trotzdem ;)