How to continuously integrate with Jenkins

Hi there!

"Continuous integration" gets thrown around a lot, but what does it really mean?

Unless you've been in a development role, it can be a little hard to define.

In short, it's a service that will automatically try to merge developer branches and test them before they are integrated into the main project code.

It's all in the effort to detect issues before they can cause real problems.

Let's get started then!

Jenkins is a time-tested tool for managing build servers, and by natural extension, continuous integration as well.

Jenkins can look a little ugly, but it gets the job done!

First, provision a server with any OS of your choosing. (Jenkins has some options now!)

Next, follow the instructions on the Jenkins site to download for your OS.

Install and let me know if you have any issues!  At the time of writing, Jenkins is now releasing v2.3 which has major changes to the setup process.

After changing the admin password, you have the option to install some suggested plugins, which is what makes Jenkins the most flexible CI tool! I highly recommend it!

One of the plugins installed is git integration, so you can easily link a Github repository with a freestyle project.

One plugin I've used in the past is the pull request builder, a great integration for larger teams where you'll want finer controls over what's being built and why.

That's really it!  Make sure to (build if necessary, and) run your test suite during the jenkins job and finally package and store to application it in your build repository for easy deployment later!

Let me know if you experience any funny business during setup and I'll add more to this guide, enjoy!

How to prepare a 15 minute demo

Hey all,

I'm giving a 15 minute demonstration on ChatOps, so I'll walk through my process while I'm at it.

Fifteen minutes isn't a lot of time to demonstrate features, so I'll need to do a fairly quick overview.

There are a few main use-cases that I want to demonstrate along with an introduction and conclusion.

Whenever I want a task to go well, I build a tool that assists in the execution of this task.

For my presentations, that tool is normally a well-rehearsed slideshow.

Usually, either Google Drive or Microsoft PowerPoint is my go-to.

Using each slide as a single idea lends to presentational structure.

Well, I need to find out how many use cases I'll be focusing on, so I can start to actually build out the presentation.

Looking... (this is a process I do when I need to borrow an experts structure so my case has a stable base)

Okay, I found four target use-cases that I can make a strong case for:

These are the use-cases StackStorm has proven successful in promoting their solution with and I should be able to do the same.

4 (use-cases) + 2 (intro/conclusion) = 6 total slides

Doing that now...

Okay, after an hour or so, here's what I got:

Not bad, but I still need to go over my oral presentational strategy.

The basic idea is for each slide:

1. introduce the overview
2. discuss the body at a high level for ~ 3 minutes 
3. then transition to the next slide.

And that's how to make a 15 minutes demo presentation.

Managing IT Outages With Icinga and StackStorm

How to pick an Orchestration component

This is a fantastic comparison I found on http://www.infoworld.com

Absolutely worth the 5 minutes read. 10/10

How to create a StackStorm Pack

What is a Pack?

Pack is the unit of deployment for integrations and automations in order to extend StackStorm. Typically a pack is organized along service or product boundaries e.g. AWS, Docker, Sensu etc. A pack can contain Actions, Workflows, Rules, Sensors.

It is best to view a pack as the means to extend StackStorm and allow it to integrate with an external systems such as Git, Google. AWS, Jenkins, etc.

Create and Contribute a Pack

Packs have a defined structure that is prescribed by StackStorm. It is required to follow this structure while creating your own pack and is also helpful to know while debugging issues with packs.

# contents of a pack folder
actions/
rules/
sensors/
config.yaml
pack.yaml
requirements.txt

In the classic Proto-Hack fashion, let's just dive right in and build your first pack!

My first pack

If you would like to create a pack yourself then follow these simple steps. In the example below, we will create a simple pack named hello-st2. The full example is also available atst2/contrib/hello-st2.

First, let’s create the pack folder structure and related files. Let’s keep the metadata files such as pack.yaml, config.yaml, and requirements.txt empty for now.



# Use the name of the pack for the folder name.
mkdir hello-st2
cd hello-st2
mkdir actions
mkdir rules
mkdir sensors
touch pack.yaml
touch config.yaml
touch requirements.txt

How to continuously integrate, test and deploy

This post will walk through the steps of setting up a continuous integration server starting with a codebase from Github, automated by StackStorm.

Step 1: Deploy stackstorm on a server, following this guide.

• There are many ways to install/deploy stackstorm, I'll be using vagrant.
• I'm using my Windows based work computer to act as the server for this example, so vagrant is a great choice for getting things up and running.
• First things first, clone the project, cd to the vagrant folder within, and "vagrant up" to get started!

And we're off!

Whoops, looks like vagrant was updated since I cloned the project! Let's fix that...

Great success! It's installed!

This will install all StackStorm components along with the Mistral workflow engine on Ubuntu 14.04 virtual machine. The setup will download additional packages from the internet. While waiting, check out StackStorm 101 Video for quick intro. If setup is successful, you will see the following console output.

Step 2: Create a sensor to integrate with repository commits.

Step 3: Create a rule to merge all branches into the master branch.

Step 4: Create a rule to run all test cases, and if successful, deploy to production server.