---

Check out how to get started with a complete Lambda delivery lifecycle in this blog post

---

Today we’ll take a look at how to deploy a Lambda function to AWS with Clarive 7.1.

In this example there is also some interesting ideas that you can implement in your .clarive.yml files to manage your application deployments, such as variables that can be parsed by Clarive.

Setup

Add the following items to your Clarive instance:

• A Slack Incoming Webhook pointing to your Slack account defined webhook URL (check https://api.slack.com/incoming-webhooks)

• 2 variables with your aws credentials : aws_key (type: text) and aws_secret (type: secret)

Slack is actually not mandatory to run this example, so you can just skip it. You can also just hardcode variables into the .clarive.yml file but you would be missing some of Clarive’s nicest features: variable management 😉

Create your 2 AWS variables in Clarive

Head over to the Admin Variables menu to setup the aws_key and aws_secret variables:

As the variable type field indicates, secret variables are encrypted into the Clarive database.

.clarive directory contents

As you can see in the following .clarive.yml file, we’ll be using a rulebook operation to parse the contents of a file:

  - aws_vars = parse:
      file: "{{ ctx.job('project') }}/{{ ctx.job('repository') }}/.clarive/vars.yml"

In this case we’ll load a file called vars.yml from the .clarive directory in your repository and the variables will be available in the aws_vars structure for later use, i.e. {{ aws_vars.region }}.

If you have a look at that directory, there is one vars.yml for each environment. Clarive will use the correct file depending on the target environment of the deployment job.

The .clarive.yml file

The .clarive.yml file in your project’s repository is used to define the pipeline rule that will execute during CI/CD, building and deploying your Lambda function to AWS.

This pipeline rule will:

• replace variables in the Serverless repository files with contents stored in Clarive

• run the serverless command to build and deploy your Lambda function

• notify users in a Slack channel with info from the version and branch being built/deployed

Slack plugin operation in use

For posting updates of our rule execution to your Slack chat, we’ll use the slack_post operation available in our slack plugin here. With Clarive’s templating features we’ll be able to generate a more self-descriptive Slack message (also called a payload):

  - text =: |
      Version:
         {{ ctx.job('change_version') }}
      Branch:
         {{ ctx.job('branch') }}
      User:
         {{ ctx.job('user') }}
      Items modified:
         {{ ctx.job('items').map(function(item){ return '- (' + `${item.status}` + ') ' + `${item.item}`}).join('\n') }}
  - slack_post:
      webhook: SlackIncomingWebhook-1
      payload:
         attachments:
           - title: "Starting deployment {{ ctx.job('name') }} for project {{ ctx.job('project') }}"
             text: "{{ text }}"
             mrkdwn_in: ["text"]

You can play around with it to experiment with different formats and adding or removing contents to the payload at will.

Replacing variables in your source code

We use the sed operation in the build step:

  - sed [Replace variables]:
      path: "{{ ctx.job('project') }}/{{ ctx.job('repository') }}"
      excludes:
        - \.clarive
        - \.git
        - \.serverless

This will parse all files in the specified path: and replace all {{}} and ${} variables found. You can find a couple of examples in the handler.js file in the repository.

Docker image

Our rule uses an image from https://hub.docker.com that has the Serverless framework already installed:

  - image:
      name: laardee/serverless
      environment:
         AWS_ACCESS_KEY_ID: "{{ ctx.var('aws_key') }}"
         AWS_SECRET_ACCESS_KEY: "{{ ctx.var('aws_secret') }}"

See that we set the environment variables needed for the Serverless commands to point to the correct AWS account.

Operation decorators

Some of the operations you can find in the sample .clarive.yml file are using decorators such as: [Test deployed application].

Decorators are used in the job log inside Clarive instead of the name of the operation. It makes it easier for the user to read the job log if operations have textual information describing what it is doing. This is specially true with longer pipelines and complex rules.

You can actually also use variables in decorators to make them more intuitive for the user!

The full .clarive.yml file is available on our Github instance:

https://github.com/clarive/example-app-serverless/blob/master/.clarive.yml

Building and deploying your Serverless app

• First, use this Github repository cloned into a new or an existing project (i.e project: serverless, repository: serverless)

Clone the new clarive repository from your git client:

git clone http[s]://<your_clarive_instance_URL>/git/serverless/serverless

Create a new topic branch. Here we’ll be tying our branch to a User Story in Clarive:

cd serverless
git branch -b story/to_github

Now commit and push some changes to the remote repository and go to Clarive monitor. It should have created a new user story topic for you and automatically launched the CI build:

From here forward, you can start the build and deploy lifecycle, including deploying to other environments (ie. Production or QA) and other deployment workflow. Just setup different variable values for each environment, so that the CI/CD pipeline will deploy to the corresponding environment when the time comes.

Enjoy!!!

---

Get an early start and try Clarive now. Install your 30-day trial here.

---