My Take on an Azure Open Source Cross-Platform DevOps Toolkit–Part 12
The Final Countdown - Testing the application in staging
We are nearing the end goal. A lot has happened already.
On the Jenkins Host - abbreviated steps
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 |
- We have downloaded both the app and all this devops code
- The app has been compiled and tested
- It has been placed into a docker container
- The app was tested inside of the docker container
- A tunnel was setup so we can run the container in staging
- The app is running in staging
- And at every stage - everything ran WITHOUT error
- We are ready for the final step - test in staging
This is final post for this series - but not the last post overall :-)
I could theoretically continue and incorporate the human approval stage.
You could extend this example to automatically deploy to the production environment based on a human approval process, perhaps using some type of web interface. Another extension point for the series of posts is to notify developers if the build breaks, if any aspect of the pipeline breaks.
These are aspects that will be added in the coming days.
Figure 1: The big picture
The Completed Pipeline
This is what the finished pipeline looks like. When we set out to build that our pipeline, the point is that it will be DevOps as code. And that’s exactly what we accomplished – we built out the entire pipeline using Python code.
Figure 2: Configuring our pipeline
The finished pipeline
You can see the steps below from 7 to 26 represents the entire execution pipeline.
We are building out line 25 now and will represent the last piece of work necessary to complete this series of posts around Jenkins pipelines.
Figure 3: The finished Pipeline in Jenkins
The goal of all of this work (All 12 posts)
What you see below is the execution of the successful bill throughout the entire pipeline without any mistakes.
Figure 4: Successfully completed pipeline
Understanding TestDockerContainerInStaging.py
17-41 | This is the method of the WebTest class that will test our application in the staging environment, which is the DC/OS cluster running in Azure data center. |
23-32 | Error trapping code that will record an error if testing and staging fails. |
34-41 | This is where we parse the resulting JSON string that comes back and validate that “Mesos” is returned to indicate we have successfully executed the unit test. |
Figure 5: TestDockerContainerInStaging.py
Validation of the app in staging
This is proof that the entire pipeline did its job. You can see here that the ultimate test is to go to the agents in a cluster and access the myapp application.
Sure enough, the correct JSON string was returned to the browser.
Figure 6: Validation that our pipeline worked correctly
Conclusion
We achieved our goal of building out an entire pipeline that runs in Jenkins, leveraging Python script to do so. Many people argue that a DevOps pipeline is basically automated execution of code, which is exactly what we achieved here.
I hope this post provided a concrete example on how to implement a DevOps pipeline which put applications into a DC/OS cluster running in Azure.
I will make some modifications in the future to have this code work with Kubernetes and Docker Swarm
And because this is a cross-platform kit, I have a fair bit of work to get this all the work in a Windows environment.