How to Build, Deploy, and Test Applications With Shippable Pipelines.
We will learn how to create an end to end deployment for a single service, and how to trigger tests every time the deployed environment or test cases are updated.
Join the DZone community and get the full member experience.Join For Free
when appropriate tools and technology are available in abundance, automation is considered the primary resource to improve the efficiency of any software development process. faster innovation cycles and speed to market are crucial to a business. with the very same principle in mind, shippable was founded so that software powered organizations could accelerate innovation. shippable provides an integrated platform, using which you can automate your software delivery from source control to production, without needing to write complex, imperative code.
in this tutorial, we will learn how to create an end to end deployment for a single service, with source code maintained in a repository on github. we will also see how to trigger tests every time the deployed environment is updated or your test cases are updated.
before you begin
here are the links for the repositories used in this tutorial.
all our tasks, task definitions, and their dependencies are defined as resources and jobs . for this setup, we will use a separate repository and define resources and jobs there. this repository will act as a syncrepo . on adding a syncrepo, shippable will read the jobs and resources ymls and create your pipeline.
we will need the following resources to successfully set up a pipeline
- syncrepo # to define our jobs and images
- gitrepo # this is where our app code resides
- an integration of type hub # to push the app image
- an integration of type deploy # to deploy our app
before we begin with our code, we will create integrations through shippable ui. we will create a dockerhub integration where we will push our image. we will also create a docker data center integration and this is where we will deploy our app. you can push and deploy your image to many other integrations that are part of the platform.
defining resources and jobs
next, define your resources and jobs in shippable.resources.yml and shippable.jobs.yml, respectively. here is how we will define resources and jobs for our pipeline.
resources: # pointer to a repository on source control - name: sampleapp_repo type: gitrepo integration: github pointer: sourcename: shipppablesamples/sampleapp branch: master # points to docker registry where we will push our image - name: dockerhub type: integration integration: "dockerhub" # points to the image that we will push - name: app-img type: image integration: dockerhub pointer: sourcename: "library/sampleapp" seed: versionname: latest # a cluster to deploy our app - name: ddc-cluster type: cluster integration: ddc-cluster # docker options that can be appended to a docker image to be pushed - name: options type: dockeroptions version: portmappings: - "51000:51000"
we will define the following 3 jobs in our jobs yml:
- a runsh job that builds our app image.
- a manifest job to generate a manifest.
- a deploy job that deploys our app.
jobs: - name: build-app type: runsh steps: - in: sampleapp_repo - in: dockerhub - out: app-img - task: - script: ./in/sampleapp_repo/gitrepo/build.sh on_success: - script: echo 'on success !!!!!' on_failure: - script: echo 'failed job .... :(' - name: sampleapp-man type: manifest steps: - in: options - in: app-img force: true versionname: latest - name: sampleapp-deploy type: deploy steps: - in: sampleapp-man - in: ddc-cluster
the first job is build-app, this job will take the resource
as the input and dockerhub integration. the git repository will be cloned into the build machine, and the dockerhub credentials are also available on the build machine. we have defined a task section which will run the script. the present at the specified location clones the repository at the location:
is the script present on the source control. this job builds a docker image and pushes it to dockerhub.
is the output of this job.
a manifest job is triggered when the
job runs successfully. the image is input to the manifest job and manifest jobs generate a new version of the manifest each time anything in the manifest changes. every time a new image is built a new manifest gets generated, or when you change the docker options which is also an in to this job.
when a manifest is generated successfully, the deploy rob is triggered and the app is deployed to the cluster which is an in to the deploy job. the ddc-cluster in this case which is defined in
adding a syncrepo
now push these files and add this repo as syncrepo from shippable ui. shippable will read the jobs and resources ymls and create your pipeline.
upon triggering the build job from the ui, the build.sh file will run and a docker image is built and pushed to docker hub. the instructions to build and push the image are in the build.sh file. here is how your pipeline will look when all the jobs run successfully. at this point, our app is deployed to the docker data center. on visiting the url for it, we can see that our app has been deployed.
running tests in pipelines
now that our app is deployed we will hook in another job into the pipelines that will test our app. all the tests are written and pushed to another repo called
bat(build acceptance test)
. we will define another job called bat which is of type
. runci jobs allow us to use ci jobs that will do acceptance tests in the pipelines.we will first go and
this project on shippable.
then define this job in our yml:
- name: bat_runci type: runci steps: - in: bat_params - in: sampleapp-deploy
this job takes the
job as input and another resource called
are some parameters that you want in your
job. tokens can be encrypted and passed as params from here. we will define bat_params in the resources yml as follows:
- name: bat_params type: params version: params: url: "www.example.com" port: 51000
if you are already using ci to run tests you can simply hook in our already existing ci job to your pipeline. also, another reason to use ci jobs to run tests is that the build images comes with preinstalled services which can be used instead of setting them up yourself. now on pushing these changes, the sync job will run and the runci job is hooked into the pipeline. now every time you deploy some changes to your app or commit some changes to your repo where you have defined your test (the repo bat in this case). the bat_runci job is triggered and your changes are tested on your app.
Published at DZone with permission of Chetan Tarale, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.