Change in IT is Inevitable, Part 2

In the second part of our series (review the part 1 here)we will discuss the development process.  This is not an all encompassing development education series, just a high level overview.  If you remember from part one the business had a need to update their application.  If we walk thru these processes, we find that in most cases we have a process that looks something like this:

· Plan

· Build

· Test

· Deliver

In the plan phase we determine what changes need to occur and then we need to be able to track those changes.  You may run across tool names like Bugzilla, Jira, Rally Software or others.  This is typically where the issues or changes to an application are documented and tracked.  This could be issues or feature requests to enhance the products.  Think about when you open a helpdesk ticket because an application does not work.  If the process of troubleshooting the issue does not fix the issue you may hear someone say they will open a bugfix or contact engineering.  These teams would utilize the information collected to try and reproduce the issues. Then determine what the course of action is to resolve the issues and move to the next step in the process.

The build phase is where the actual changes or new application is written depending on the requirements.  The types of programming languages used can vary greatly but a short list are Java, C#, Python, Ruby/Rails etc… Editors are another piece of the puzzle that will be used to modify the programming code.  Depending on the type of language you may be able to use any text editor, things like Notepad ++, Sublime or Atom depending on the features or libraries that you need to load.  In some cases you may need a different editor like Eclipse IDE for Java, Visual Studio for C#.  These can vary based on personal preference, available integrations, language and many other elements.

Once you have your code changed or updated you will want to save it somewhere.  Not just save it but make sure you have a revision so you can go back to a starting point if needed.  These repositories can either exist on premise or off depending on your requirements.  Tools like Github, Subversion and Bitbucket are common ones.  These repositories allow you to share and work with other team members on projects.

As we start to put this all together, there may be different iterations of what teams may use.  This is just a high level idea to talk to but in the diagram you can see these processes start to integrate and have dependencies on one another.  One process may kickoff another let’s say that a test of new code passes and that kicks off the release of the code to production.

That leads us into the build and test part of the process.  This is where different elements of the code are tested, it may be something simple like log into a web site 100 times in a minute and then order a product 100 times.  It may test functionality or response times based on the criteria you are evaluating.  It would depend on if you are trying to enhance user performance or solve an issue that was reported.  There are a number of products in this space as well and the most common I see are Jenkins, Selenium and JMeter but there are a lot more.  There are also other terms that get thrown around a lot and may be unclear like DevOps, Continuous Integration and Continuous Delivery.  They are different so let’s try and clear up our understanding before moving on.

DevOps is a cultural change that focuses on the delivery of a service and typically relates to agile methodology.  There is no software alone that solves this problem; think of it as a process framework that helps teams work together to accomplish a common process.

Continuous Integration is a way that development teams integrate their code via a repository.  Then utilizing a method to validate the code through automation of builds.  Think about this as how the infrastructure is built and code is tested.  I write some code and save it to a repository, that save kicks off a job that builds my infrastructure, runs another process that tests to make sure the code did what it was supposed to and then logs the information.

Continuous Delivery builds on the CI process whereby it allows code to be released to production.  That said DevOps can drive CI or CD but they are not necessarily dependent on each other. CD typically is that process that drives the code to production.

Artifacts are repositories that bring similar features of a code repository but are typically utilized for binaries, libraries or other software packages.  YUM is a great example of where you pull packages for Linux builds.

As for the provision and deploy phase there are again numerous methods to provide the underlying infrastructure to support the application.  These could also run in parallel as an example you may want to utilize VMware vRA as the portal that calls the OS template to deploy the linux servers required for the application stack, then Puppet is utilized to validate and push down the configuration i.e. username, file systems and then another process runs as a post deploy that brings in the Docker container with the application and a plugin from vRA integrated to Jenkins kicks off the testing process.

Looking back at the Continuous Delivery process now we can see that we can set parameters that allow code to be released to production if a set number of tests pass or back to the drawing board if it fails.  There are also other factors that like feedback loops which may be logging application data that provides information on where code failed or didn’t pass from a testing standpoint.  These can be very complicated or very simple depending on the application and the develop process within an organization.  I encourage you to spend a little time and understand the business drivers and process around delivery of these services.

In the next section we will discuss options around the infrastructure.  Hopefully this back ground on the development process has helped provide you a better understanding of the challenges and why the business is looking for infrastructure services delivered in a different method.

Next we will talk to what those services might look like and yes talk about everyone’s favorite subject, cloud.