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.
If you work in the Information Technology Services Industry, sooner or later you will run into a project that’s driven purely by dates and milestones. The challenge with such projects, is that the dates and milestones where pre-defined during the initial planning phase of the project or during the RFP where the customer asked for a work plan with milestones. For the scope of this blog, project and program will be used interchangeably.
What are the dates and milestones missing? Simply, expert or quasi expert estimates from the vendors and domain experts. The team that answered the RFP or performed the initial project planning as part of a Program Management Office (PMO) provided a guesstimate (guess estimate). Granted, all projects and programs need a project plan with an initial baseline so that the project teams can kick-off phase of their relative projects.
A living “schedule”: The big mishap here – is that the schedule does not become a living document due to contractual constraints or the political cloud that surround all organizations. Often, delivery dates and milestones are unchangeable. Our PMP governing body is completely ineffective when the schedule is not managed. Schedule management is the key to a successful project/program.
Scope Creep: The customer wants additional functionality that’s outside the statement of work or project charter. With a weak PMO, this will cause the project to fail because the project teams will be increasing their scope. Scope management is the key to successful program delivery. Without scope management, the project teams will be aiming at a moving target.
Schedule Slippage: When the project starts to slip to the right – the System Integrator or the Vendor will make the case to add more resources with justifiable metrics and other pertinent decision making data. From the customer’s perspective, this is a win-win situation; “you add more consultants and we get the functionality that we need”. This is not the case. This is one of the biggest pitfalls in program management and in non Agile programs. This combination is lethal to the success of program. Here are the misconceptions with such an approach.
- Mythical Man Month – “Adding more resources to a project that’s already late, will delay the project even further” Why? Because valuable resources that are delivering functionality will have to come of the assembly line in order to train the new resources. (Fred Brook – http://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959)
- Delivery Team Coverage: Since the schedule is not being managed, the delivery team will have to work over-time (OT) in order to make up for the lost time that they never had to begin with. OT – only works in the short term before the team enters the law of diminishing marginal returns. What I mean by this is that the Production Index or Velocity for a project team will reach its climax at a given point in time and the productivity will not increase but rather decrease due to fatigue and other factors .Work Life Balance for the delivery team will be non-existent. (I have live through several of these projects)
- Got Middle-Management (MM)? – If you are a delivery manager and you can’t manage the Work Breakdown Structure (WBS) nor the schedule; then, you are set up to fail. The challenge is that the WBS and project schedule are not realistic nor portray the actual tasking that it’s taking place. This leads to the status reporting and more status meetings. The latter part drives most teams away from interfacing with the “status keepers” and alienates the delivery team from MM. The “us” versus “them” culture starts to take place and the delivery team will start to become dysfunctional.
- Got Status? – Anytime a project slips, the hierarchy of reporting becomes greater and more time consuming. Everyone, who never showed interest on your effort will now zero in on your team and add additional organizational pressures. Valuable resources will have to allocate additional time for status meetings that were non-existent before the slip.
Next Post will have recommendations on how to deal or manage such challenges.