Integrations with Amazon Web Services

Of all supported Buddy integrations one of the most popular are Amazon Web Services. There are currently 5 AWS services supported by dedicated actions with more to come in the future (depending on the community feedback):

Deploy to Amazon S3

Together with Elastic Beanstalk and EC2, one the most successful Amazon service. A lot of web developers use S3 to store static files (sometimes entire static pages). With Buddy, you can define a pipeline that will automatically upload repository files to the selected S3 Bucket on push to branch. You can add additional actions that will process your files prior to the deployment, eg. Grunt or Gulp.

Example pipeline:

The project is PHP. Static assets, such as videos, PDFs, Javascript, CSS and image files are kept in an S3 bucket. On every push to the master branch Buddy will test and upload your website to the SFTP server + and update assets on AWS S3.

{% vimeo 207609434 %}

Deploy to Elastic Beanstalk

AWS Elastic Beanstalk is a classic PaaS service, similar to Heroku or Google App Engine. It lets developers upload, build and serve their code, leaving infrastructure configuration and scaling at the AWS side.

Example pipeline:

Deployment to Elastic Beanstalk is based on uploading a zip file with the application code. Buddy lets you create a pipeline that will upload the package automatically on push, on demand, or recurrently at a given time. Just like with S3, you can add build and test actions before the deployment.

{% vimeo 207609443 %}

You can also Dockerize your apps first and deploy them Elastic Beanstalk later:

Build and push Docker image to ECR

Amazon EC2 Container Registry is a Docker image storage for AWS developers.

Example pipeline:

To build a Docker image, you need a repository with the application code and a dockerfile with instructions how the image should be built. You can configure Buddy to build a new Docker image and push it to the ECR on every push to the selected branch. It’s also possible to add an SSH action that will pull the Docker image on the selected host and launch the new version of the application.

You can read more about building Docker images in this article

Selecting ECR registry in Docker image build action

Run Lambda function

AWS Lambda allows developers run code without provisioning servers. It scales to the size of the application and execute only when required, from a couple of requests per day to thousands of operations per second. With Buddy, you can automate deployment of Lambda functions to S3 buckets or trigger the functions with a dedicated Lambda action.

Example pipeline:

Let’s assume we have a web application with backend executed in Lambda functions. Both backend and frontend is stored in the same repository. The pipeline for that could look like this:

  1. Build and test application on every push to repo
  2. If all tests have passed, use Lambda function to perform backup
  3. Deploy application frontend to SFTP server
  4. Upload updated backend files to Amazon S3 with another Lambda function
Details of Lambda action

Deploy to CodeDeploy

CodeDeploy is a tool that facilitates application deployment to EC2 instances and custom user servers. The whole process boils down to uploading the app to CodeDeploy via S3, with the rest of operations handled entirely by AWS.

Example pipeline

Let’s assume we have a Node.js project that requires performing Gulp tasks and tests before the deployment. With Buddy, you can create a pipeline that will, for example, execute all of the above once a day at midnight – provided there were any changes at all in the repository. If one of the actions has failed, a notification with the error description will be sent to the selected Slack channel.

Example Gulp-CodeDeploy-Slack pipeline

Appendix: AWS Policies required by Buddy

In order to make the AWS actions work properly, you need to define the policies for them. You can find the complete list of policies here.

Buddy v1.4.39 Released

New features

  • Something BIG is coming. Stay tuned.

Improvements

  • Better support of submodules in the Code tab
  • If you have two or more integrations of one type (eg. AWS) the list of integrated items in the action settings (eg. S3 buckets in Deployment to S3) will now display the ID’s of their parent integration
  • Every AWS action now displays the list of policies it requires. You can find the full list here

Bug fixes

  • Fixed bug with uploading files from the filesystem to a relative path on SFTP server

Feature spotlight: Building Docker images

With Buddy you can build your own Docker images with source code from GitHub, Bitbucket and GitLab (or Buddy) repositories. In this release we’ve added context path support for Docker image builds—a good opportunity to present how to automate the delivery workflow for dockerized applications.

Docker app workflow

The workflow for the dockerized app is defined in a dockerfile kept in the repository along the source code and looks like this:

  1. Changes to application code
  2. Unit tests
  3. Build Docker image
  4. Push Docker image to registry
  5. SSH to the application server
    • Docker pull from registry
    • Stop current Docker container
    • Start new version

Buddy lets you save time and money by automating these steps so that you can focus purely on application coding.

Location of Docker image build action

Automating Docker build with Buddy

In this paragraph we’ll show you how to automate build and push to registry. As a result, on every change in the repository a new version of the application image will appear in the registry. You can fork this repository and use it as template, or use your own:

  1. Create a new project in Buddy and select the repository with the application
  2. Add a new pipeline, assign it to the Master branch, and set the trigger mode to On every push
  3. Add the Docker image action and select the dockerfile and context path that will be used for building the application.

TIP: Usually the dockerfile is located in the directory in which the image is built. However, sometimes the code structure requires the dockerfile to be moved somewhere else. In this case, you need to provide the context path.

  1. Select the registry to which the image will be delivered (Docker Hub, Amazon ECR, Private)

TIP: You can use Buddy parameters to define the tag with which the image will be pushed, for example ${execution.id} or ${execution.to_revision.revision}. This way every execution will create a new version of the image in the registry with an adequate tag.

  1. (Optional) Depending on the host you build your image on, you may want to use different variables to define the image values. These arguments are available upon clicking More options.

Once you add the action, every push to the repository will automatically build a new Docker image and push it to the registry with no need for action. You can also run the action manually:

{% vimeo 207809264 %}

Adding tests before Docker build

The principle rule of Continuous Deployment is that your code is always tested before it is deployed to the production server. This also applies to the code that you use to build your images. With Buddy you can automatically test every change pushed to the repository by adding a build action before building the Docker image:

  • Add Node.js at the beginning of the pipeline and define your tests. You can install any missing dependencies in the Packages & Setup tab

When ready, make a push or run the pipeline manually and watch Buddy execute your tests.

{% vimeo 207794574 %}

Re-running the Docker container after the build

The application is tested and the image is built. At this moment the image is usually run on a server. This too can be handled with Buddy:

  • Add the SSH action at the end of the pipeline, provide your server details and enter these commands:

      docker pull image:tag
      docker stop containername|| true
      docker run --name containername -d image:tag
    

TIP: You can use environment variables to store your credentials.

SSH action details

Buddy GO: the Docker-based CI server with deployment tools

Buddy GO is a Docker-based CI server with Git hosting that you can install and use behind your own firewall. It sports the same features as the cloud instance of Buddy but is hosted and managed entirely on the premises. This is important for companies whose privacy policy requires to keep the code in-house, or for developers in remote areas with lagging internet connection.

Buddy v1.4.38 Released

New features

  • New action: Build Docker image with context paths

Improvements

  • Better support of errors for Rackspace deployments and Maven/Gradle builds
  • AWS Lambda now supports all AWS regions
  • Added commiter name and commiter email to Buddy parameters (useful eg. when sending notification of new version to Slack)

Feature spotlight: PHP Unit

PHPUnit is a popular programmer-oriented testing framework for PHP. You can use it to test your code before the deployment so that you know the copy on your server is free of errors.

PHPUnit action details

Configuring tests and delivery with Buddy

There’s still a wide range of developers who haven’t heard or don’t know how to introduce Continuous Integration to their process. Buddy lets you set up the whole workflow in 10-15 minutes (either through GUI or YAML) and easily scale and expand once your projects grow bigger.

  1. Create a new project, choose your Git provider, and select your PHP repository.
  2. Add a new pipeline and switch the trigger mode to On every push
  3. Add PHPUnit action. You can install any missing modules in the Packages & Setup tab
  4. Add FTP/SFTP file transfer action and configure your deployment

TIP: You can also add the SSH action and use it, eg. to run composer install on your server.

This way every time you’ll make a push to the selected branch, Buddy will automatically test and deploy the changes to the server + run the desired SSH commands:

PHPUnit workflow

If your tests require a database to run, eg. MySQL, you can easily activate them in the Services tab:

Attaching database

A good practice is to add a conditional notification in the end that will send you a message in case the tests or the deployment have failed, for example to your Slack channel:

Slack conditional notification

Summary

If you’d like to learn more about using Buddy in PHP development, check out our guides on automating PHP dependencies and Wordpress themes with Buddy.

Happy coding!

New action: Rackspace Cloud Files

Deploy files to Rackspace Cloud Files with the new file transfer action!

Rackspace Cloud Files is an online storage for large files and media: images, video, audio, as well as HTML, JavaScript and CSS files. The service ensures fast access to its content with a CDN utilizing over 200 servers around the world. Rackspace also provides developer tools for Java, Python, Node.js, Ruby, PHP, and .NET.

In order to deploy to Rackspace Cloud Files you need to provide your username and access token generated in your Rackspace account.

Rackspace Cloud Files

Introducing: Expanded GitHub Integration

Since GitHub is the #1 Git provider among our users, we have decided to deepen the integration with the service by enabling the status of Buddy operations in the GitHub GUI.

The status will be visible in the following sections:

  • Code/Commits
  • Code/Branches
  • Pull requests
Pull request details

Use case: Pipeline as a build server

You can configure Buddy to automatically test your application on every push to any branch in your GitHub repository:

  1. Create a new project, choose GitHub as your provider, and select the repository that you want to use
  2. Create a new pipeline, set the trigger mode to On every push + set the Wildcard pattern to *
  3. Add a build action that will run the tests

This way every new commit pushed to the GitHub repository will be immediately tested with the results posted in GitHub.

Branch list on GitHub

Use case: Pipeline as a delivery tool

Another use case is configuring Buddy as a deployment tool for your Production server:

  1. Create a new project, choose GitHub as your provider, and select the repository that you want to use
  2. Create a new pipeline, set the trigger mode to Manual + assign the pipeline to your Master branch
  3. Add a file transfer action for your type of server (FTP/SFTP/cloud service, etc.)

Such pipeline will also send information to GitHub: you’ll be able to see which revision is currently deployed on the server on the commit history list. If for some reason the deployment hasn’t finished successfully, a proper label will be applied.

Commit history with labels

Introducing: Configuration as Code (YAML)

Pipelines – the visual representation of a developer’s workflow – are one of the core features that make Buddy easy to use and configure. However, some of the developers prefer the classic way of managing configuration using YAML files.

This is especially true for users who:

  • have used another CI/CD software before and find it hard to switch to the GUI
  • need to store the history of configuration changes in the repository
  • want share their config files with other users
  • eat, code and sleep in their terminal :)

This is why we’ve decided to add support for YAML files as an alternative way of configuring pipelines. The option is available in the right column of the Pipelines tab.

TIP: IMPORTANT: Upon switching to the YAML mode any existing pipeline in the project will be removed. You can reproduce the pipelines by copying the configuration from YAML box and pushing it to the repository as buddy.yml. Please mind that the feature is still in beta and requires some polish, so any feedback is highly appreciated.

The complete documentation on how to use YAML in Buddy is available here.

Buddy YAML

Get started now

14 days of unlimited trial. No credit card required.