Creating a Serverless Application Project with Jenkins CI/CD

Spinning up a serverless application sounds simple—until you try to automate it. That’s where Jenkins steps in. If you’ve ever manually deployed Lambda functions and thought, “this should be automated,” you’re in the right place.

Let’s walk through creating a serverless application project and wiring it into a Jenkins CI/CD pipeline that handles builds, tests, and deployments without manual effort.

What “serverless” actually means in this setup

We’re not talking about “no servers exist.” Instead, we’re delegating infrastructure management to a cloud provider like AWS. In this guide, the core pieces are:

• AWS Lambda (compute)
• API Gateway (HTTP interface)
• IAM roles (permissions)
• Jenkins (automation)

The goal: every commit triggers Jenkins to build and deploy your serverless app automatically.

Project structure (keep it simple)

A clean layout helps Jenkins understand what to build and deploy. Here’s a minimal example:

1serverless-app/
2  ├── handler.js
3  ├── package.json
4  ├── serverless.yml
5  ├── Jenkinsfile
6  └── tests/
7

If you’re using Python instead of Node.js, swap handler.js with app.py. The rest stays conceptually similar.

A basic Lambda handler

1exports.hello = async (event) => {
2  return {
3    statusCode: 200,
4    body: JSON.stringify({ message: "Hello from Jenkins-powered serverless!" })
5  };
6};
7

Defining infrastructure with serverless.yml

This file is the backbone of your serverless application project. It describes what gets deployed.

1service: jenkins-serverless-app
2
3provider:
4  name: aws
5  runtime: nodejs18.x
6  region: us-east-1
7
8functions:
9  hello:
10    handler: handler.hello
11    events:
12      - http:
13          path: hello
14          method: get
15

This tells AWS to create a Lambda function and expose it via an HTTP endpoint.

Where Jenkins fits in

Here’s the idea: Jenkins becomes your deployment engine. Every push to your repository triggers a pipeline that:

• Installs dependencies
• Runs tests
• Deploys the serverless app

No manual AWS Console clicks. No forgotten steps.

Creating the Jenkins pipeline

This is where things get interesting. Instead of configuring jobs in the UI, define everything in a Jenkinsfile.

pipeline {
  agent any

  environment {
    AWS_REGION = 'us-east-1'
  }

  stages {
    stage('Install Dependencies') {
      steps {
        sh 'npm install'
      }
    }

    stage('Run Tests') {
      steps {
        sh 'npm test'
      }
    }

    stage('Deploy Serverless App') {
      steps {
        sh 'npx serverless deploy'
      }
    }
  }
}

This pipeline assumes:

• Node.js is available on the Jenkins agent
• Serverless Framework is installed (or installed via npx)
• AWS credentials are configured in Jenkins

Configuring AWS credentials in Jenkins

A common mistake developers make is hardcoding credentials. Don’t do that.

Instead:

• Go to Manage Jenkins → Credentials
• Add AWS Access Key and Secret
• Use environment bindings or plugins like AWS Credentials Plugin

Then reference them safely in your pipeline.

Triggering builds automatically

You don’t want to manually click “Build Now.” Configure Jenkins to react to code changes.

• Use GitHub webhooks or GitLab hooks
• Enable “Poll SCM” if webhooks aren’t available

Once set up, every commit kicks off your serverless deployment pipeline.

A quick end-to-end flow

Here’s what happens after everything is wired:

1. You push code to your repository
2. Webhook notifies Jenkins
3. Jenkins pulls the latest code
4. Dependencies are installed
5. Tests run
6. Serverless Framework deploys to AWS
7. API endpoint updates automatically

No human intervention needed.

Common pitfalls (and how to avoid them)

1. Deployment timeouts

Serverless deployments can take longer than expected. Increase Jenkins stage timeout if needed.

2. Missing IAM permissions

If deployment fails, it’s often due to insufficient AWS permissions. Ensure your IAM user or role can:

• Create Lambda functions
• Manage API Gateway
• Write CloudFormation stacks

3. Environment drift

What works locally might fail in Jenkins. Keep environments consistent using:

• Docker agents
• Explicit Node versions

Performance and scaling notes

One benefit of serverless is automatic scaling, but your pipeline should also scale:

• Use parallel stages for tests if needed
• Cache dependencies between builds
• Avoid full redeploys if only small changes occur

For larger teams, consider splitting pipelines into build and deploy jobs.

Why Jenkins still makes sense here

You might wonder: why Jenkins when cloud-native CI/CD tools exist?

Jenkins shines when:

• You already have existing pipelines
• You need flexibility across multiple environments
• You’re integrating with legacy systems

It’s not the newest tool, but it’s still one of the most adaptable.

Wrapping it up

Creating a serverless application project with Jenkins is less about complexity and more about wiring the right pieces together. Once your pipeline is in place, deployments become predictable, repeatable, and fast.

If you’re currently deploying manually, even a basic Jenkins pipeline like this can save hours—and prevent mistakes that only show up in production.

From here, you can expand into multi-stage deployments, blue-green strategies, or even multi-region serverless architectures. But this foundation gets you shipping reliably today.