Continuous Delivery vs Continuous Integration

See More

The question I want to address in this post is, whether Continuous Delivery is important or Continuous Integration. Before delving deep into this discussion there are two things I would want to say,

  • This post is intended towards developers fairly familiar in building applications but struggling to know how the build process can be automated
  • There would be some references to a particular programming environment (.NET in particular), and that in no way means the concepts are irrelevant to other programming languages and their development setup. Irrespective of the application development language in question the build process is something which is common across all application development.

Every application we as programmers/developers/engineers write needs to be deployed. Whats the best way to deploy a certain application? Thats what the process Continuous Integration talks about.

Continuous Integration – Mechanism that enables you to build your non-trivial code regularly. How regularly? As regularly as possible. (If you have a Version Control setup, then as regularly as you checkin).

Continuous Delivery – Pushing out code to production on a regular basis. By production I mean to real non-trivial customers who would be using it regularly.

There are a plethora of articles on the interweb that talk about how to setup a continuous integration for the choice of language. The point of this article is to get familiar with the concept rather than deals with the nuts and bolts of the setup. Continuing, Just imagine this scenario.

Continuous Integration in 200 words or less (don’t care)

A: You’ve written a piece of code well and good. Now you want to test it. How would you do it?
B: Ohh, do you mean just test it, how about running unit tests?

A: Ahh, unit tests test a certain piece of code and see if proper values are returned and handles all failures gracefully during the course of execution. In this process it ignores the external dependencies (mocking). How do you assure functionally it is working the way it is intended to?
B: (F5) in a Visual studio would run the application. And yay!!! I test it.

A: Seriously, How reliable is just running Unit tests? How would I deploy the application for actual use? Still use (F5)?
B: Ahh….! No clue.

The pain you need to go through everytime you need to run tests, compile, copy the binaries over to a test setup. Then testing it, and again pushing to production, it’s unbearable. Imagine the whole nine yards being automated. How easy would it be to on a button click tests are ran, builds completed and deployed to the environment of choice (test or staging or prod). Imagine how much time that saves. Thats ontinuous integration. In a fast paced development environment where turn around time is very quick, it’s quiet important to have a setup like the one mentioned above.

So far we talked about Continuous Integration, turning our attention to Continuous Delivery, as simple as said it is a way in which at regular intervals the software is released for its intended users. It is not as simple as it sounds. There’s a lot of material that goes into Continuous Delivery.

For the next few posts, am going to talk about the concept of Continuous Integration, how can it be used to make an application better. How to achieve Continuous Delivery, are there any methodologies in place? What are they and so forth.

Why am I doing this?
I’ve been working in the domain of enabling Continuous Integration and Continuous Delivery for the past 2 years and I’ve got a liking as to what goes on into enabling this feature for large enterprises. And what I relaized is if CI and CD principles are adhered through the smallest piece of code a lot of hassles are removed. Yes you heard me right, when the process of continuous integration and delivery are adhered too the team as such becomes responsible to the code it is delivering. That’s my inspiration.

See you around soon for the next part.

Note:
There have been few good thoughts put in as books on both Continuous Integration and Continuous Deployment. Those books are highly relavant and must be read for those opting to get into such a cycle.

[1.] Continuous Delivery, http://www.amazon.com/gp/product/0321601912
[2.] Continuous Integration, http://www.amazon.com/Continuous-Integration-Improving-Software-Reducing/dp/0321336380/
[3.] http://martinfowler.com/books/continuousDelivery.html

Options to get Apache service started when port 80 is blocked

My academic project is web oriented, I have an installation of wamp bundle on my windows vista machine and I decided to dabble with PHP after a long time. The trouble was not from PHP as I expected, but it was from a very unexpected corner.

When I was starting the services from the wamp icon available in the system stray, I noticed the apache service was not running, when I tested the port (through the test port 80 option available in the apache block), I noticed the following message:

Your port 80 is actually used by
Server: Microsoft-HTTPAPI/2.0

The reason for my surprise was, I made sure the IIS service was stopped on my machine(Control Panel/Administrative Services – Go to IIS right click and press stop.) and the error message in-fact surprised me. To find the services that were running on port 80, I tried

netstat -o -n -a | findstr 0.0:80

And I found a process with pid – 4 was running, eventually from this I found out PID 4 is used by the NT Kernel. This article pointed me out in the right direction as I had the SQL Server services running on my machine but I decided to play safe as I was not well acquainted with the ins and out of the windows system.

I resolved the problem by changing the port number from which apache service ran. Open the <DIRECTORY>/wamp/Apache2/conf — here I opened the httpd.conf file, found for “Listen”, you will encounter a para similar to the one below

# Listen: Allows you to bind Apache to specific IP addresses and/or
# ports, instead of the default. See also the <VirtualHost>
# directive.
#
# Change this to Listen on specific IP addresses as shown below to
# prevent Apache from glomming onto all bound IP addresses (0.0.0.0)
#
#Listen 12.34.56.78:80
Listen 80

Commented the line Listen 80 and added Listen 8080, so all the requests are now heard from the port 8080.

# Listen: Allows you to bind Apache to specific IP addresses and/or
# ports, instead of the default. See also the <VirtualHost>
# directive.
#
# Change this to Listen on specific IP addresses as shown below to
# prevent Apache from glomming onto all bound IP addresses (0.0.0.0)
#
#Listen 12.34.56.78:80
#Listen 80
Listen 8080

I hope this helps someone, who has similar trouble setting up wamp on the VISTA or windows 7.