My Take on an Azure Open Source Cross-Platform DevOps Toolkit - The Beginning - Part 1
| My Take on an Azure Open Source Cross-Platform DevOps Toolkit–Part 1 | Click Here |
| My Take on an Azure Open Source Cross-Platform DevOps Toolkit–Part 2 | Click Here |
| My Take on an Azure Open Source Cross-Platform DevOps Toolkit–Part 3 | Click Here |
| My Take on an Azure Open Source Cross-Platform DevOps Toolkit–Part 4 | Click Here |
| My Take on an Azure Open Source Cross-Platform DevOps Toolkit–Part 5 | Click Here |
| My Take on an Azure Open Source Cross-Platform DevOps Toolkit–Part 6 | Click Here |
| My Take on an Azure Open Source Cross-Platform DevOps Toolkit–Part 7 | Click Here |
| My Take on an Azure Open Source Cross-Platform DevOps Toolkit–Part 8 | Click Here |
| My Take on an Azure Open Source Cross-Platform DevOps Toolkit–Part 9 | Click Here |
| My Take on an Azure Open Source Cross-Platform DevOps Toolkit–Part 10 | Click Here |
| My Take on an Azure Open Source Cross-Platform DevOps Toolkit–Part 11 | Click Here |
| My Take on an Azure Open Source Cross-Platform DevOps Toolkit–Part 12 | Click Here |
In the next few posts I will describe my take on how I would automate the building, testing, and deployment of applications for both Windows and Linux. I have already written all the Python code to do this. I will show you step by step.
The goal of the code base was to keep it as small and tight as possible so that you could take the work here and expand it to meet your needs. I tried to avoid heavy levels of abstraction and modularization and to make it as readable as literal as possible. I find the best approach for me is to first write everything as inline as possible. There is no code reuse or heavy object-orientation, although there is some.
Click image for full size
Figure 1: The Big Picture
At the bottom of this post you can see all the Python modules that I have written.
There will be a few phases to getting this done. In the first phase, you will up your environment. The starting environment will be on an Ubuntu virtual machine. it works with trustee, 14.04 and above.
I am going to assume that you can follow the steps to install the necessary tooling. I'll show you some of the things to think about but I am assuming that you can get the basic software installed on your own. This includes Python, Gradle, Java, Jenkins, as well as some of the supporting libraries (packages) that Python allows you to use.
Click image for full size
Figure 2: The big picture
DevOps is mandatory and modern computing environments
We can all agree that automating your application delivery pipeline is the new world order. Countless enterprises and startups are jumping on board with this technology. The ability to automate the testing and compiling of applications is crucial. It is well documented that this approach to delivering applications leads to higher profits for companies, happier customers, and, in general, higher-quality software.
Click image for full size
Figure 3: Ultimately, it is about happy customers
My take on DevOps
So what I would like to do in the next few posts as described my approach to solving some of these problems. There are countless other examples out there on the web but I had some specific goals in mind.
Click image for full size
Figure 4: Test, test, test
Core Principles
Keeping it concrete and clear
First, the code should be as literal and simple as possible, but still demonstrate some of the more difficult problems to solve.
Cross-platform and interoperable
Second, ultimately I want to support a very similar workflow for both Windows-based applications as well as Linux.
It’s about containers
Third, containerization is the core technology that is driving the DevOps revolution. So, our Java application will be deployed to a container.
Click image for full size
Figure 5: The scripting language is supported on Windows and Linux
Almost all enterprises have both Windows and Linux workloads
Fourth, I want to create as cross-platform a code base as possible, so that I can use a very similar pipeline for both Windows and Linux.
Test, test, test the whole way through. And then test again.
Fifth, I want to have the application tested at almost every stage of the process.
When to test
When the developer compiles their code
- After the developer checks in their code
- After the build server compiles the application
- After the application is bundled into a Docker container
- After the container is deployed to a staging environment
- After the container is deployed to production
The Technologies-Windows and Linux
Our build environment needs to be flexible in terms of being able to compile and deploy and test both Windows and Linux applications inside of containers. So, in this series of blog posts I will be deploying a Java-based application and Linux. And for windows I will be deploying a C#-based web app. I will begin with the Linux example.
The Java-based application
I will be working with a Java program that accesses a MySQL database and returns Jason. Essentially, it is a basic restful or HTTP endpoint that retrieve data from a MySQL database. Nothing fancy here. The goal is to containerize and test this application and deploy it to production at the end of the pipeline.
The Build Server - Jenkins
The build server will include Jenkins, which is arguably the de facto standard today to automate builds and deployment pipeline’s. The latest incarnation of Jenkins servers provides a new concept called “pipeline.” Rather than forcing Jenkins users to use their wizard-like workflow, the new “pipeline” approach allows you to totally script your building deployment process. I find this approach exceedingly satisfying because I don’t want to waste my time clicking around the Jenkins user interface to build out my workflow. Instead, I want to have a nice readable, code-based series of scripts that perform the automation. This also protects me from changes in the Jenkins UI and eliminates manual steps.
An important part of scripting the pipeline is choosing the right scripting language. To me it makes sense to leverage Python. First, Python is an awesome and beautiful language that includes object oriented features and has been proven over the test of time to be effective. In addition, Python is cross-platform so that I can build out my scripts to execute both under Windows and in Linux. In my opinion this is an exceedingly important point. You don’t want to have separate scripts for both Windows and Linux. Large enterprises who must support heterogeneous environments need to choose a language that is in your operable everywhere.
Stay tuned for next post that drills into this more.
Click image for full size
Figure 6: The End Game