Throughout the previous chapters, you have learned how to develop an application based on microservices. Now, it is time to learn about the deployment of your application, learning the best strategies to automate and roll back your application and also, doing back ups and restores if needed.
As we mentioned in Chapter 5, Microservice Development, Composer is the most-used dependency management tool; it can help us move a project from the development environment to production in the deployment process.
There are some different opinions about what the best workflow for the deployment process is, so let's look at the advantages and disadvantages of every case.
To be used on the development environment, Composer provides a section on their composer.json, called require-dev, and when we need to install some libraries on our application that do not need to be on production, we have to use it.
As we already know, the command to install a new library using Composer is composer require library-name, but if we want to install a new library, such as testing libraries, debugging libraries, or any others that do not make sense on production, we can use composer require-dev library-name instead. It will add the library to the require-dev section and when we deploy the project to production, we should use the --no-dev parameter when executing composer install --no-dev or composer update --no-dev in order to avoid installing development libraries.
With the .gitignore file, it is possible to ignore files or folders that you do not want to track. Even though Git is a versioning tool, many developers use this in the deployment process. The .gitignore file contains a list of files and folders that will not be tracked on your repository when they change. This is usually used to upload folders that contain images or any other file uploaded by users and also, it is used for the vendor folder, the folder that contains all the libraries used on the project.
The vendor folder contains all the libraries used in our application. As previously mentioned, there are two different ways of thinking about how to use the vendor folder. There are advantages and disadvantages of including Composer in production in order to get the vendor folder from the repository once the application is deployed or when it is downloading the libraries used on development into production.
The deployment workflow can be different in every application depending on the project needs. For example, if you want to keep the whole project, including the vendor folder, in the repository or if you prefer to get the libraries from Composer once the project is deployed. We will look at a couple of the most common workflows in this chapter.
The first deployment workflow has the entire application on the repository. This is when we use Composer for the first time in our development environment and we push the vendor folder to our repository, so all the libraries will be kept on the repository.
Therefore, on production we will get the entire project from the repository without needing to do a Composer update because our libraries were put in production with the deployment. So, you do not need Composer in production.
Advantages of including the
vendor
folder in the repository are as follows:
- You know that the same code (including libraries) was working on development.
- Minor risk of breaking updated libraries in production.
- You do not depend on external services in the deployment process. Sometimes, the libraries are not available at a specific moment.
Disadvantages of including the
vendor
folder on the repository are as follows:
- Your repository has to store libraries already stored on Composer. The space needed can be a problem if you need many or large libraries.
- You are storing code that is not yours.
The second deployment workflow has two different ways of proceeding, but both of them do not need to store the vendor folder in the repository; they will get the libraries from Composer once the code is deployed to production.
Once the code is deployed to production, the composer update command will be executed either manually or automatically in the deployment process.
Advantages of running Composer in production are as follows:
- You are saving space in your repository
- You can execute–optimize-autoload in production in order to map the libraries added
Disadvantages of running Composer in production are as follows:
- The deployment process will depend on external services.
- Major risk in some situations when updating packages. For example, if a library is suddenly modified or corrupted, your application will break.
It is necessary to know that it is possible to have management dependencies on the frontend side too, so it is possible to choose if it is better to put it on the repository or not. Grunt and Gulp are two of the most used tools in order to automatize tasks in your application. Also, if your application based on microservices has a frontend part you should use the following tools in order to manage styles and assets.
Grunt is a tool to automatize tasks on your application. Grunt can help you to concat or minify JS and CSS files, optimize images, or even help you with unit testing.
Every task is implemented by a Grunt plugin developed on Javascript. Also, they use Node.js, so it makes Grunt a multiplatform tool. You can check all the available plugins at http://gruntjs.com/plugins.
It is not necessary to learn Node.js, just install Node.js and you will have Node Packaged Modules available to install Grunt (and many other packages). Once Node.js is installed, run the following command:
npm install grunt-cli -g
Now, you can create a package.json that will be read by the NPM command:
{
"name": "finding-secrets",
"version": "0.1.0",
"devDependencies": {
"grunt": "~0.4.1"
}
}Then, npm install will install the dependencies contained in the package.json file. Grunt will be stored in the node_modules folder. Once Grunt is installed, it is necessary to create a Gruntfile.js to define the automated tasks, as shown in the following code:
'use strict';
module.exports = function (grunt) {
grunt.initConfig({
pkg: grunt.file.readJSON('package.json'),
});
//grunt.loadNpmTasks('grunt-contrib-xxxx');
//grunt.registerTask('default', ['xxxx']);
};There are three sections to define the automated tasks:
- InitConfig: This refers to tasks that will be executed by Grunt
- LoadNpmTask: This is used to load the required plugin to make the tasks
- RegisterTask: This registers the tasks that will run
Once we decide what plugin to install and define all the necessary tasks, run grunt on your terminal to execute them.
Like Grunt, Gulp is also a tool to automatize tasks and it is also developed on NodeJS, so it is necessary to install Node.js in order to have NPM available to install it. Once we have installed Node.js, we can install Gulp globally by running the following command:
npm install -g gulp
Another way of installing gulp, and is the recommended option, is locally and you can do it with the following command:
npm install --save-dev gulp
All the tasks should be included in a gulpfile.js located on the root project to be automated:
var gulp = require('gulp');
gulp.task('default', function () {
});The preceding code is very simple. As you can see, the code is gulp.task, the task name, and then the function defined for that task name.
Once you have the functions defined, you can run gulp.
CSS is complex, large, and hard to maintain. Can you imagine maintaining a file with thousands and thousands of lines? This is where Sass can be used. This is a preprocessor that adds features, such as variables, nesting, mixins, inheritance, and others to CSS that makes CSS a real development language.
Syntactically Awesome Stylesheets (SASS) is a metalanguage of CSS. It is a script language that is translated to CSS. SassScript is the Sass language and it has two different syntaxes:
- Indented syntax: This uses the indent to separate block codes and the new line character to separate rules
- SCSS: This one is an extension of the CSS syntax, it uses braces for code blocks and semicolons to separate lines within a block
The indented syntax has .sass extensions, and SCSS has .scss extensions.
Sass is very simple to run. Once it is installed, just run sass input.scss output.css on your terminal.
Bower is a dependency management like Composer, but it works for the frontend side. It is also based on Node.js, so once Node.js is installed, you can install Bower using NPM. Using Bower, it is possible to have all the frontend libraries updated, without needing to update them manually. The command to install Bower once Node.js is installed is as follows:
npm install -g bower
Then, you can execute bower init in order to create the bower.json file on your project.
The bower.json file will remind you of composer.json:
{
"name": “bower-test”,
"version": "0.0.0",
"authors": [
"Carlos Perez and Pablo Solar"
],
"dependencies": {
"jquery": "~2.1.4",
"bootstrap": "~3.3.5"
"angular": "1.4.7",
"angular-route": "1.4.7",
}
}In the preceding code, you can you can see the dependencies added to the project. They can be modified in order to have these dependencies installed on your application like Composer works. Also, the commands to work with Bower are very similar to Composer:
- bower install: This is to install all the dependencies on
bower.json - bower update: This is to update the dependencies contained on
bower.json - bower install package-name: This installs a package on Bower