In my earlier blog post on using Bluemix to deploy a simple Cloud Calendar on Bluemix, I added something the next day or so that discussed using the Deploy to Bluemix button for an even Easier Cloud Calendar. Well my post has gotten some responses from within IBM, with various different teams wanting to use this simple cloud based calendar to provide a simple widget that they can use to provide a team calendar capability on their RTC dashboards. So now I have a few different teams that would like me to deploy this simple solution for them.
Well I started out just showing people how they could do this themselves on Bluemix, because it really is quite easy. However, some of the people asking for this are not technical types, they’re business type or (worse) management types. They are afraid or unable to do this for themselves. I’ll address the fear of cloud in a different blog post in the future. The main thing here is that I ended up using the same code (or similar code) to deploy about 4 different types of calendars for 4 different groups within IBM.
How do I manage to do this without driving myself crazy? I use the DevOps services available to me in Bluemix, and I configured a delivery pipeline that allows me to build, test, and then deploy four different variants of the same basic application. The project was already out there in the Bluemix hosted Git repository, what I needed to do is to make some small changes to how I deploy, and some small changes for each flavor (or variant) of my application.
Overview
The original application was a Node.js app, and was pretty simple. For details on it, view my original blog post called How About a Generic Calendar in the Cloud?. Now to deploy this project, I went into my Test Calendar project and clicked on the Build & Deploy button. This brought me to the Build and Deploy pipeline area. I then looked and saw a simple build already set up for my Node.js project. This simple build executes every time I push new changes to the master branch of my Git repository. That’s perfect, I now have a continuous build (not to be confused with Continuous Integration) environment set up for my project.
Simple Deploy
Next I need to add a new stage to my project. So I add a new stage to deploy my test configuration. This stage takes the outputs of the build stage as inputs, and deploys these out to my test calendar environment. This “test environment” is a simple application/MongoDB pair that I have out in the Bluemix staging environment. Now since I have multiple instances that I want to deploy, under different names, in different Bluemix environments/spaces, I will need different manifest.yml files. The manifest.yml file indicates where the application gets deployed, and the services that it will use.
So I decide to create multiple manifest.yml files, with a naming convention that indicates which deployment they belong to. So I have a manifest_TestCalendar.yml file with the settings for my TestCalendar (which is my test configuration), and a manifest_ToxCalendar.yml file with the settings for my team calendar (which is my production configuration). I actually have five of these, but I’ll keep it simple and just highlight the two for the purposes of explaining things here. So my manifest_TestCalendar.yml file looks like this:
applications:
- disk_quota: 512M
- services:
- mongolab-TestCalendar
host: TestCalendar
name: TestCalendar
random-route: true
path: .
domain: stage1.mybluemix.net
instances: 1
memory: 512M
declared-services:
mongolab-TestCalendar:
label: mongodb
plan: 100
and my manifest_ToxCalendar.yml file looks the same, except for the host line (which specifies “ToxCalendar”), the name line (which specifies “ToxCalendar”), and the declared services (which name a different MongoDB instance). Note that the name of the Mongo DB service instance MUST match the name of the service as shown in Bluemix. You’ll need to go and create that service first, before you try using this to spin up new instances of your application. Also note that the route here is pointing at an internal IBM instance of Bluemix, if you do this in the public Bluemix, you’ll use mybluemix.net as the domain.
Configuring the Test Stage
Back to our deployment pipeline. When I look at the pipeline, I decide to leave the first stage of deployment set to automatically deploy by leaving the stage trigger set to “Run jobs when the previous stage is completed”. This means that this stage will run when the build stage successfully completes. Now since I want to have a continuous integration environment, the target of this deploy should be my test instance. What I will have isn’t really a true continuous integration environment, as I don’t have any automated tests being run as part of the deployment, but you can see how you can easily modify the stage to support this.
So we’ve decided to do an automated deploy of my test instance on any build. Go click on the gear icon in the stage, and chose Configure Stage. You will now see a dialog box where you can configure your DevOps pipeline stage. In this dialog, check the Input tab to make sure that the stage is set to be run automatically, by making sure that the Run jobs when previous stage is completed option is selected. Then click on the Jobs tab and make sure that you have a Deploy job selected (if you don’t, then go and create one). The Deployer Type should be set to Cloud Foundry, and the Target (where this should be deployed) should be your Bluemix environment. Once you select the target, your organization and space drop-down selections should get populated with organizations that you are a part of, and the spaces available in those organizations (For more on organizations and spaces in Bluemix/CloudFoundry, read Managing your account). Also enter in your Application Name in the field provided, and make sure that this application name matches the name of the application in your Bluemix console, as well as the application name that you used in the manifest.yml file. In this case, it is the name of the application that we used in the manifest_TestCalendar.yml file, which was “TestCalendar”.
Finally you will see a grey box with the deploy script. Now in order to make sure that we use the manifest_TestCalendar.yml file to deploy this, we have to copy this over the existing manifest.yml file. It is a simple Unix/Linux copy command, and your resulting deploy script should now look like this:
#!/bin/bash
# Move proper manifest file into place
cp manifest_testCalendar.yml manifest.yml
# push code
cf push "${CF_APP}"
# view logs
#cf logs "${CF_APP}" --recent
The result of this is that we copy the version of the manifest file that we want into place, and then CloudFoundry just does the rest. Go ahead and make a simple code change (just update a comment, or the README file), commit and push it (if you’re using Git), and watch as the application gets automatically built, and then the test calendar gets deployed.
Configuring the Production Stage
Now if we want to deploy using the same mechanism for our production instance, the process is simple. We just click on the gear icon in the stage, and chose Clone Stage. This creates a new stage, just like our stage to deploy our test instance. Click on the gear icon for this new stage. You will now see a dialog box where you can configure your cloned DevOps pipeline stage. In this dialog, check the Input tab to make sure that the stage is NOT set to be run automatically, by making sure that the Run jobs only when this stage is run manually option is selected. Then click on the Jobs tab and make sure that you have a Deploy job selected. The Deployer Type and the Target (where this should be deployed) should remain the same. Once you select the target, your organization and space drop-down selections should get populated with organizations that you are a part of, and the spaces available in those organizations. If you want to deploy your production instance to a different organization and space, you will change the settings for these fields. Enter in your Application Name (for the Production application) in the field provided, and make sure that this application name matches the name of the application in your Bluemix console, as well as the application name that you used in the manifest.yml file. In the case of my production instance, it is the name of the application that we used in the manifest_ToxCalendar.yml file, which was “ToxCalendar”.
Finally you will see a grey box with the deploy script. Now in order to make sure that we use the manifest_ToxCalendar.yml file to deploy this, we have to copy this over the existing manifest.yml file. We’ll need to modify the cloned deploy script to reflect this change:
#!/bin/bash
# Move proper manifest file into place
cp manifest_ToxCalendar.yml manifest.yml
# push code
cf push "${CF_APP}"
# view logs
#cf logs "${CF_APP}" --recent
The result of this is that for the production stage, we copy the version of the manifest file that we want (manifest_ToxCalendar.yml) into place for use by CloudFoundry. Since this has been configured as a manual stage, you now will only deploy a new version of your production calendar when you manually drag a new build to the stage.
What does it mean?
Now we have a deployment pipeline built that allows us to do automated builds and deployments of changes to our calendar application to the test environment. It should look something like the picture on the right.
Once we are satisfied with our changes, we can then just drag the appropriate build from the App Build stage, and drop it on the stage where we deploy to production (Deploy to Bluemix Staging – Production in the picture). This will start the deployment process for the production instance of our calendar application.
What about different variants of our calendar application?
Now we can use this same technique of having multiple file variants to support different deployed “flavors” or variants of our calendar application. I do the same thing with the Node code in the index.html file of the calendar application. This file is in the public subdirectory. I can create two variants of this file, and save them in different files (say index_ToxCalendar.html and index_TestCalendar.html). The change to the index_TestCalendar.html file is the addition of a single line of code, which will display a heading on the calendar. The code snippet looks like this:
<body onload="init();">
<div id="scheduler_here" class="dhx_cal_container" style='width:100%; height:100%;'>
<center><b>TEST CALENDAR</b></center>
<div class="dhx_cal_navline">
The single added line just puts a title line (“TEST CALENDAR”) in the application. For other instances, I can make similar changes to similar files. To get the deployed application to use the correct version of the index.html field that I want, I need to make one more modification to the deploy script. It should now look like this:
#!/bin/bash
# Move proper manifest file into place
cp manifest_testCalendar.yml manifest.yml
# Move proper index.html file into place
cp public/index_TestCalendar.html public/index.html
# push code
cf push "${CF_APP}"
# view logs
#cf logs "${CF_APP}" --recent
Now we have a specific variant for our test calendar, deployed to the test environment. You would then do similar changes and file variants for all of the other deployed variants of this that you want to deploy and support.
Dan Toczala's Blog 