This post was originally published on http://snoozy.ninja/.

Continuous deployment (CD) is a software engineering approach in which software functionalities are delivered frequently through automated deployments.

Continuous deployment ?

One of the 'latest' trends in the IT world (more specifically in the DevOps part) is continuous deployment and continuous delivery. Google Trends illustrates it quite well:

The process of adapting the project to this methodology requires changes related to the code itself as well as to the organisation of work. Automation and simplification of software delivery stages is a very important stage. Today I would like to show you how to easily configure and run automatic deploying of an application written using Vue CLI.

One of the stages of the software development process is code review. During this stage, a person who is not the author of the code, reviews it and checks if there are any errors in the code. During this process, especially when creating a web application, it may be very useful to run a new version of the application to see how it works and looks like.

Of course, you can download the code that was added to the pull request and run it yourself, but very often running the application does not belong to trivial processes (it may turn out, for example, that we need to run some other services). That is why it is best to automate this process completely. Thanks to this, each branch will have an address, where its built and working version will be available.

The automation process is very closely related to the tools we use to test and build our application. In the example below I decided to use gitlaba and Amazon s3. Of course you can replace these elements with other services. Any CI tool like travis, jenkins can replace gitlab. Instead of S3 you can use any kind of hosting (I recommend github pages which can be used for free).

Our process will look like this:

• Developer creates a new branch locally and makes changes in the code.
• When the new branch is 'pushed' into our repository, our pipeline starts to work. Pipeline will build and deploy the current version to s3.
• During the review process, after each update of our branch (or pull request) the new version will be automatically added. The old version will still exist.
• When branch is removed or mired to the master, our pipeline will remove the no longer needed trial version.

AWS configuration

Creation of a new bucket

The first step will be to create a place where we will 'upload' new versions of our application. Because my application is a simple application, which was built using VueCli we can use s3. If you don't know what Amazon S3 (Amazon Simple Storage Service) is, it's enough for you to know that This is a simple service that allows you to keep files in the cloud. It has a very easy to use web interface, which allows you to store and manage their data. The amount of stored data is theoretically unlimited. However, you must be aware that all files will be publicly available. You will be able to view any file that is added to S3. If you have some 'secrets' in your code do not use s3 for hosting your application!

Let's start with creating a new 'bucket'. Bucket is nothing else but a place where our application will be kept. The bucket's name will determine the address where our application will be available. Remember that if you want to use another domain you will need to name your bucket exactly the same as your domain name. Otherwise you will have a problem if you want to use Route53 (This is another aws service, which is responsible for dns). The creation of a bucket we can do at this link. Just click 'Create new bucket' and enter its name. The bucket name must be available globally (this is related to how S3 works).

The final version of our bucket should look like this:

Now we have to do one more thing - we have to enable the option that will allow us to host our files. It is very simple and boils down only to indicating the file to be shown by default (index.html). Options can be found under the tab 'Properties'

Now is the right time to add a policy for our bucket. We would like it to be read-only for every person.
Our policy should be as follows:

Gits

Adding a new user

The second step is to create a user. This will be the user who will be used to perform operations on s3. We will set the user's access rights, which will allow him to manage our bucket. It will add files and delete them, when they become unnecessary. A new user must have a policy that looks like this:

Gits

Pay attention to line 9. Change it to match the name you used as your bucket name.

The last thing to do is to download the access keys. They are available under the tab "security credentials". Remember that you can only see them once. We will need them when configuring our gitlab.

Gitlab configuration

The process of preparing our pipeline is simpler. The only thing we have to do is to copy this file and save it as .gitlab-ci.yml.

Gits

We must remember to add our security credentials to the CI/CD settings in the gitlab settings.

Let us now discuss the most important elements of this file.

Docker

Gitlab pipelines use a docker image, which helps us to configure the environment needed in the process of testing / building the application.It is worth noting that in each stage they can have their own version of docker (line 31). It is useful because during the building process of application we will need elements related to node, but during deployment, we will need an image that has a python installed.We need it because we will use the awscli that we will use to copy our files to a remote s3 service. Thanks to this one line, within a few minutes after adding our changes to the repository we can test them in a working environment.

Review deployment stage

The main magic begins in the deploy_review section. In this stage, our application (which was built in the build step) will be added to s3. Let's look at the command that copies files.

aws s3 cp dist s3://${BUCKET_NAME}/${CI_COMMIT_REF_SLUG}/${CI_COMMIT_SHA} --recursive

Our variables are respectively:

• ${BUCKET_NAME} is the name of the bucket.

• ${CI_COMMIT_REF_SLUG} is the name of the current branch.

• ${CI_COMMIT_SHA} is the hash of the current heada.

The address where our application will be something similar to:

https://test5555.s3-website.us-east2.amazonaws.com/fix_123/${CI_COMMIT_SHA}

For the master branch, we have very similar behavior. Only that instead of the name of the branched files will be copied under the main address (e.g. https://test5555.s3-website.us-east2.amazonaws.com).

After the review process, when the branch will be merged or rejected, we would like our application to be also deleted from s3.The code between lines 48-59 is responsible for this.

Application configuration

There is also one thing to remember. Since our application will be available at different addresses, it should be taken into account in the building process. The variable VUE_APP_ROUTER_BASE is used for this purpose. It defines the address
where our application will be located available. When building versions from a branch, set it to branch name.

Summary

As we could see, configuring the automatic deployment of our test version is very simple and brings you only to correctly configure hosting service and add .gitlab-ci to our project. Such trial versions may be used to check the application during the review, but it may well be the first step to create integration tests that will be run on our code.