How to build and deploy front-end applications with Buddy

In this short guide, we'll show you how to manage dependencies and build a front-end application with Gulp, and deploy it safely to the server.

Deploying front-end is not easy anymore

Back in the day, everything was simple: you just uploaded HTML to the server, maybe with some (badly) compressed pictures. Nowadays, most web applications require to be built before the deployment. The process usually looks like this:

• first, you fetch dependencies (npm, Composer, Yarn, Bower)
• then, you concatenate and minimize assets, styles, and scripts, etc. etc. (Gulp, Grunt, Webpack, Babel)

All the tools listed make it easier to work on the project: keep dependencies under control, improve application performance, and as a result deliver better code, optimized and free of errors.

However, there's one little thing in the development process when things might get out of hand: deployment.

Like we already said, previously you just uploaded the files to the server and, bang, the release was ready. Some developers think they keep it simple today by keeping the dependencies (vendor, node_nodules dir, etc.) and compiled assets in the repository. If you are one of these developers, please STOP IMMEDIATELY. These things should never have found the way to your repo!

Never store dependencies and compiled artifacts in the repository

• A repository with dependencies and artifacts is growing very fast. Git has not been designed to cope with large files, and the bigger the size of a file, the worse it performs
• If you store artifacts in the repository, you need to remember to compile the application before every commit, so you can commit the altered artifacts together with the changes to the source code. It's very risky because if you forget to update the artifacts in the repo, deploying your application to Production server may cause serious problems.
• The tasks that you use to compile, minimize and concatenate files may produce different results: it's enough that developers on your team use different versions of Node.js. Committing such files to the repository will incite constant conflicts that need to be solved manually. This makes branch merges very troublesome.
• An application compiled in version X of Node.js may not work properly in version Y – yet another human factor issue which makes it difficult to be 100% sure that the generated artifacts are compatible with the Node version on the Production server.

Deploy has more steps

Okay, so now that we know keeping artifacts and dependencies in the repository is not a good idea, the question is: how should we deploy our application to the server? Without a Continuous Deployment tool, it usually looked like this:

1. The application is uploaded to the server via SFTP/SCP or Git and built with a script that will download the dependencies and run the tasks directly on the server
2. In case the SSH access is not available (eg. the server is FTP) the application must be built in a compatible environment before the deployment

Never deploy manually

The previously mentioned human factor adds to the overall length of the release. What's worse, it may generate errors very hard to pick up and diagnose.

All in all, the whole deployment process should be streamlined down to a single operation:

• a script parameterized with a revision that you can run with a command in the terminal
• a tool or application that will let you automate the process

How to deploy front-end applications with Buddy

In this part of the guide, we'll show you how in 5 minutes to create a delivery pipeline that will automatically fetch dependencies and run Gulp tasks.

Sign up at Buddy

Go to https://buddy.works and sign up with your GitHub/Bitbucket account or email address.

Select Git provider and repository

Buddy supports GitHub, Bitbucket, GitLab, or any other external repository. You can also use its fully-featured native hosting with merge requests and branch permissions.

Image loading...

Create a delivery pipeline

Configure the branch that you want to deploy, and set the trigger mode: manual (on click), automatic (on push), or recurrent (on time interval).

Image loading...

Add a build action

Choose the build action for your type of project that will fetch the dependencies and build your application. In our case we want to download Node modules and run Gulp tasks, so select the Node.js action:

Image loading...

Provide the build commands for the application and select your Node version:

Image loading...

Make sure to save the changes to add the action to the pipeline.

Add a deployment action

The application is built and ready to be uploaded to the server. Buddy lets you deploy code almost everywhere:

Image loading...

For the purpose of this guide, we'll choose the good old FTP. Once you click the action, you will be prompted to select where you want to deploy the files from. Make sure to select the Filesystem, as it holds the application built in the previous step:

Add a notification action

In the end, it's a good practice to add an action that will keep us informed of finished deployments. If you use your task manager to run tests, you can also add a conditional notification that will send you a message in case the tests have failed. The whole pipeline will then look like this:

Image loading...

Now, make a push to the triggering branch and watch Buddy automatically build and deploy your application the very way it should be done.

Use case #1: Building an application on the Production server

If your server supports SSH, you can configure Buddy to build your app directly on the server after the deployment by adding the SSH action to the pipeline:

Image loading...

Use case #2: Deploying assets to an S3 bucket

In case your application requires large static files (eg. videos) it's a good practice to host them in a hosting service like Amazon S3, preferably with CDN enabled for quicker access. You can easily create a pipeline that will:

• build your app
• deploy it to FTP (without assets)
• deploy assets to Amazon S3
• invalidate CloudFront to purge the cache

Image loading...

Other use cases

The possibilities in which you can put Buddy's pipelines to practice are virtually unlimited and involve things such as:

• deploying files to Elastic Beanstalk and EC2
• updating apps on Heroku
• using Buddy as a CI server to run unit, integration and Selenium tests
• building Docker images and pushing them to the registry
• monitoring your apps and websites for downtime

It all depends on your needs and the profile of your workflow: just sign up at buddy.works with your GitHub or Bitbucket account, give it a spin, and let us know what you think!