Chapter 10. Deploying Your App

In this chapter, we'll cover the following topics:

• Setting up Forge, AWS, and CodeDeploy

• Setting up Travis to auto deploy when all is passing

• Working with your .env file

• Testing your application on production with Behat

• Making a composer package out of our client

Introduction

All of these recipes around building have left out one key step—deploying. This is something I would have done from the start, typically. Ideally, as you show progress to a product owner or work with a team, your work is not truly done until it is merged with other work and seen on a staging area. Having something work on your machine is really half the battle.

This chapter will go over some key steps to getting you application to deploy. I will look at the easy-to-use workflow with Forge, but then I will also add a bit extra to it. Also, I will then cover testing your production app with Behat and managing your .env file.

Finally, I will pull out the client that I have been using all along to make a library, that out of it shrinking down the code I am testing and deploying.

Setting up Forge, AWS, and CodeDeploy

Forge has changed the game. Taylor Otwell did an amazing job of making it super easy to put an app online. I want to show you how to use this with AWS and CodeDeploy. Digital Ocean is an amazing service, but sometimes, you need to use AWS as per the customer requirement, or more importantly, you want to benefit from a lot of the features that it provides.

Second, I want to show CodeDeploy since it can deploy Artifacts. The killer feature I know is that what is working on Travis CI will work on the server, since I do not need to do another Git pull, composer install, Gulp, and so on. But I am just copying over a zipped artifact of the application in a passing state.

In the steps that follow, we are going to perform the following:

1. Setting up Forge

2. Setting up the EC2 with a role that will allow it to work with CodeDeploy

3. Setting up the EC2 to work with Forge

4. Setting up the EC2 to listen for CodeDeploy pushes

5. Setting up an S3 to store the Artifacts

6. Setting up an...

Setting up Travis to auto deploy when all is passing

Level 0 of any work should be getting a deployment workflow set up. What this means in this case is that a push to GitHub will trigger our CI. And then from the CI, if the tests are passing, we trigger the deployment. In this example, I am not going to hit the URL that Forge gives you, but I am going to send an Artifact to S3, and then have CodeDeploy to deploy this Artifact.

As you will see in Chapter 4, Building Views and Adding Style under the Using Travis to run tests on every push section, I have covered setting up this app in Travis CI (https://travis-ci.org/); in this section, I will cover adding CodeDeploy as a part of this step.

Getting ready

You really need to see the section before this, otherwise continuing to know this will make no sense.

How to do it…

The following are the steps:

1. Install the travis command-line tool in Homestead as noted in their docs at https://github.com/travis-ci/travis.rb#installation. Make sure to use Ruby...

Working with your .env file

The workflow around this can be tricky. Going from Local, to Travis CI, to CodeDeploy, and then to AWS without storing your information in .env on GitHub can be a challenge. What I will show here are some tools and techniques to do this well.

Getting ready

A base installation is fine; I will use the existing installation to show some tricks around this.

How to do it…

1. Minimize the .env variable using Conventions as much as possible:

   1. config/queue.php I can do this to have one or more Queues:

      

   2. config/filesystems.php:

   

2. Use the Config file as much as possible. For example, this is in my .env:

   

   But I can also add config/marvel.php, and then make it look like this:

   

   My .env file can be trimmed down by KEY=VALUES later on I can call to those:

   • Config::get('marvel.MARVEL_API_VERSION)

   • Config::get('marvel.MARVEL_API_BASE_URL')

   

3. Now, to easily send to Staging or Production using the EnvDeployer library, run the following:

   >composer require alfred-nutile-inc/env-deployer:dev-master...

Testing your app on Production with Behat

So, your application is now on Production! Start clicking away at hundreds of little and big features, so you can make sure everything went okay; or, better yet, run Behat! Behat on Production? Sounds crazy, but I will cover some tips on how to do this, including how to set up some remote conditions and clean up when you are done.

Getting ready

Any application will do. In my case, I am going to hit production with some tests I made earlier.

How to do it…

The following are the steps to be followed:

1. Tag a Behat test called @smoke or just a scenario that you know is safe to run on Production, for example, features/home/search.feature:

   

2. Update behat.yml by adding a profile to it called production:

   

3. Then run the following:

   > vendor/bin/behat -shome_ui --tags=@smoke --profile=production
   

   Tip

   I run an Artisan command to run all of these.

   Then, you will see it hit the production URL and only the scenarios you feel are safe for Behat.

4. Another method is to log in as...

Making a composer package out of our client

One practice you will start to do a lot is making packages you can use in other projects. In this example, I will start to move the Marvel client into its own namespace and rename it UniversalComicClient. Then, once this is working, I will pull it completely out and put it onto Packagist.

Getting ready

A fresh installation of Laravel is fine. The code for the client can just be moved around in there.

How to do it…

1. Make a new folder called app\UniversalComicsClient\src as we are going to make this a universal client.

   Tip

   Later, I will rename all of this Comic singular.

2. Then move the files here:

   • app/UniversalComicsClient/src/MarvelApiClient.php

   • app/UniversalComicsClient/src/ComicClientInterface.php

   • app/UniversalComicsClient/src/MarvelApi.php

3. Update all these namespaces to be YourGithubName\Package, so in my case Alnutile\UniversalComicsClient example:

   

   Provider Boot

   Tip

   Alnutile is my GitHub name, and in this case, it is my vendor name.

4. Now, set up the local...