How to deploy correctly when using Composer's develop / production switch?

Question 1

Composer has the option to load several dependencies only while being in development, so the tools will not be installed in production (on the live server). This is (in theory) very handy for scripts that only make sense in development, like tests, fake-data-tools, debugger, etc.

The way to go is to add an additional require-dev block with the tools you need in dev:

"require-dev": {
    "codeception/codeception": "1.6.0.3"
}

and then (theoretically) load these dependencies via

composer install --dev

Problem & Question:

Composer has changed the behaviour of install and update dramatically in 2013, require-dev-dependencies are now installed by default (!), feel free to create a composer.json with a require-dev block and perform an composer install to reproduce.

As the most accepted way to deploy is to push the composer.lock (that holds your current composer setup) and then do an composer install on the production server, this will also install the development stuff.

What's the correct way to deploy this without installing the -dev dependencies ?

_{Note: I'm trying to create a canonical Q/A here to clarify the weird Composer deployment. Feel free to edit this question.}

Question 2

Why

There is IMHO a good reason why Composer will use the --dev flag by default (on install and update) nowadays. Composer is mostly run in scenario's where this is desired behavior:

The basic Composer workflow is as follows:

A new project is started: composer.phar install --dev, json and lock files are commited to VCS.
Other developers start working on the project: checkout of VCS and composer.phar install --dev.
A developer adds dependancies: composer.phar require <package>, add --dev if you want the package in the require-dev section (and commit).
Others go along: (checkout and) composer.phar install --dev.
A developer wants newer versions of dependencies: composer.phar update --dev <package> (and commit).
Others go along: (checkout and) composer.phar install --dev.
Project is deployed: composer.phar install --no-dev

As you can see the --dev flag is used (far) more than the --no-dev flag, especially when the number of developers working on the project grows.

Production deploy

What's the correct way to deploy this without installing the "dev" dependencies?

Well, the composer.json and composer.lock file should be committed to VCS. Don't omit composer.lock because it contains important information on package-versions that should be used.

When performing a production deploy, you can pass the --no-dev flag to Composer:

composer.phar install --no-dev

The composer.lock file might contain information about dev-packages. This doesn't matter. The --no-dev flag will make sure those dev-packages are not installed.

When I say "production deploy", I mean a deploy that's aimed at being used in production. I'm not arguing whether a composer.phar install should be done on a production server, or on a staging server where things can be reviewed. That is not the scope of this answer. I'm merely pointing out how to composer.phar install without installing "dev" dependencies.

Offtopic

The --optimize-autoloader flag might also be desirable on production (it generates a class-map which will speed up autoloading in your application):

composer.phar install --no-dev --optimize-autoloader

Or when automated deployment is done:

composer.phar install --no-ansi --no-dev --no-interaction --no-plugins --no-progress --no-scripts --optimize-autoloader

If your codebase supports it, you could swap out --optimize-autoloader for --classmap-authoritative. More info here

Question 3

After a discussion on the composer-user list this has been fixed in

https://github.com/composer/composer/commit/05d9912f97a2decf6a5c08dfa569dcf23d79b16d

If anyone else runs into this, update composer to the latest version using

composer selfupdate

Question 4

I would suggest you take a look at this: https://getcomposer.org/doc/03-cli.md#environment-variables

COMPOSER

By setting the COMPOSER env variable it is possible to set the filename of composer.json to something else.

For example:

COMPOSER=composer-other.json php composer.phar install

The generated lock file will use the same name: composer-other.lock in this example.

Question 5

You need to copy that assemblies to production server into Microsoft SQL ServerMSSRSReporting ServicesReportServerbin folder. Then back to ReportServer folder and open rssrvpolicy.config file to grant FullTrust permission to CodeGroup with name Report_Expressions_Default_Permissions and CodeGroup with class name FirstMatchCodeGroup.

Question 6

In order to allow public access to your Self-hosted OWIN Web API app. Follow following Steps:

Allow Inbound Connections from Firewall

Run wf.msc command to open up Windows Firewall with Advanced Security and add a new Inbound Rule for TCP port 8000 or the port you want to use.

You can make sure your service is getting request by opening <machine public ip>:8000 from other machines.
Get Static IP from ISP

Request your ISP for static IP. Most of the times ISP charges extra for that. If you already have static IP, skip this step and move to next step.
Point your domain to static IP

Lastly, go to your domain DNS Manager and add an A Record with Host Name = www and IP Adress = <your machine static IP>.

You might also need to add another A Record with Host Name = @ and IP Adress = <your machine static IP> if you want also want to access your service without www.

The procedure of adding A Record varies. You can simply read knowledge base documents provided by your registered on how to add A Record.

How to deploy correctly when using Composer's develop / production switch?

Problem & Question:

Answers

php,deployment,composer-php