The good folks at Bitnami have made a large number of applications available via VM’s for all the major cloud platforms. One of my favorite CI tools is Jenkins, which as you guessed Bitnami offers multiple VM’s and local images. If your sys admins don’t have time to set up a Jenkins server for you, then you can easily deploy a Jenkins to AWS or Azure or Digital Ocean.. you name it.
In this post we are going to show you how easy it is to set this up on Azure. It’s just as easy on all other providers. One of the advantages of Azure is that your server will have the hostname DNS resolvable without the need for a static IP.
Here are the steps.
1. Sign up for Azure
2. Sign up for a Bitnami account.
3. Open the following URL.
4. Follow the simple steps to get the .publishsettings file. Then, Select the Machine size and region.
5. Create the Jenkins Server. Don’t forget to name your server something meaningful.
6. Server is being Created.
7. Server is created…
Once the server is created, login to your Jenkins server and start configuring “Items”. This was a breeze! Thank you Bitnami. On my next post, I will show you how to configure Jenkins with Github and Salesforce Chatter as part of a CI process for Salesforce’s Apex – force.com
It’s has been a while since I posted on this blog. Now that I have aligned all my ducks in a row, walked the dog and fed the cat it’s time to blog again.
I can’t address enough the benefits of Continuous Integration on IT projects. In a nutshell, CI is a software development methodology that is based on the premise that developers check their code into source control multiple times a day. The code check-in triggers an automated build which compiles all the code and runs unit tests. Thus, a software development team has many integrations in a day.
As Agile methodologies continue to overtake the traditional Waterfall, yes waterfall is not dead yet, we can witness CI become a key activity in driving software quality. Quality is driven by the many integrations and the early identification of software defects during the automated builds.
Working as an adviser to many project teams, another key activity that it’s missed is the “Demo”. Whether you use Scrum, Kanban or any other methodology, be sure that your team gets to demo what they built iteratively Recently, I was on a project where the development team did not demo their application until the last week of the development cycle and the customer had a large number of changes that they wanted. Unfortunately for this customer, the Waterfall approach that the System Integrator was using did not take into account this simple activity. Instead, the changes were logged as “Change Requests” and left to another process in order to define the priority.
How do we fix this symptom? If you are in a Waterfall vacuum, try to schedule a few demo’s with the stakeholders either a product owner or a system user. Get feedback early in the process and incorporate the changes that are within the scope of the SOW. If the changes or feedback fall outside of the SOW, the notify your customer and log the request on a risk register.
Also, incorporate CI into Waterfall. Have your team stand-up a build server and have them check their code with unit tests. Build often and reward the build breaker with a special hat or task.