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 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 minimise 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 artificats 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, minimise and concatenate files may produce different results: it’s enough that developers on your team use different versions of Node.js. Commiting 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 artifcats 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:
- 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
- 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 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 BuddyWorks
In this part of the guide we’ll show you how in 5 minutes to create a delivery pipeline that will automatically fetch dependendencies and run Gulp tasks.
Sign up at BuddyWorks
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.
Create 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).
Add 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:
Provide the build commands for the application and select your Node version:
Make sure to save the changes to add the action to the pipeline.
Add deployment action
The application is built and ready to be uploaded to the server. Buddy lets you deploy code almost everywhere:
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 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:
Now, make a push to the triggering branch and watch BuddyWorks automatically build and deploy your application the very way it should be done.
Use case #1: Building application on 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:
Use case #2: Deploying assets to S3
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
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 https://buddy.works with your GitHub or Bitbucket account, give it a spin, and let us know what you think!