Enduring Continuous Deployment Integration Using Depicted
Creating a killer websites is hard, but deploying them is sometimes even harder. Developing and deploying sites is best accomplished using a methodology called continuous deployment integration. By working towards automating all testing and deployment tasks, developers can generally avoid big surprises and a painful deployment experience–but perhaps there’s a way to ease the learning curve and bring about smarter continuous deployment.
Enter Depicted, a project developed by Brett Slatkin: not just another DevOps tool, but a way to visualize the changes between incremental web deployments to ease the strain of the continuous life-cycle.
Introducing Depicted: Safe continuous deployment
Brett Slatkin, the co-founder of Google Consumer Surveys and co-creator of the PubSubHubbub protocol, has introduced Depicted–an automated end-to-end safe continuous deployment workflow. Depicted makes continuous deployment safe by comparing before and after webpage screenshots for each release. It shows when any visual, perceptual differences are found.
“Continuous Deployment relies on a multitude of automated tests to increase confidence in the quality of code and deployments. In addition, manual testing is necessary to prevent unforeseen errors,” says Brett.
The open source, Apache 2.0 licensed is the ultimate, automated end-to-end test tool for deployment of websites. Written in Python, it uses Flask and SQLAlchemy to make it easy to run in your environment. Depicted workflow has API server for capturing screenshots and automatically generating visual images.
At Velocity 2013 conference in Santa Clara, Brett presented a method for visual regression testing. According to Brett, Depicted will increase confidence in the deployment process, which will lead to shorter deployment cycles and shorter ramp-up phases.
How it works?
Depicted works by establishing a baseline release with an initial set of screenshots of your site. It then creates a new release with a new set of screenshots of your new version and manually approves or rejects each difference and mark the release either as bad or good. The workflow will then repeat the same process and will automatically be compared to the last known-good version within that build. The approved release will then become the baseline for the next one.
A release cycle has separate test runs. A test run is a single screenshot of a single page and is named as the path of the URL being tested. The life-cycle of a release contains four stages – Created (a new release is created with a specific name), Receiving (release is waiting for all test runs to be requested or reported), Processing (all test runs have been reported) and Reviewing (all test runs have been processed).
API for Developers
Slatkin created an API on the test instance of Depicted located at https://dpxdt-test.appspot.com. The API server uses HTTP Basic Authentication to verify your client has access to your builds and requests all the response on JSON. The API server runs ImageMagick and PhantomJS as subprocesses on App Engine.
Links for Developers
Repository: https://github.com/bslatkin/dpxdt
WebSite: http://www.onebigfluke.com/2013/06/introducing-depicted-safe-continuous.html
Discussion Forum: https://groups.google.com/forum/?fromgroups#!topic/dpxdt/-plf_qnGXwk
Demo: http://youtu.be/UMnZiTL0tUc
API: https://dpxdt-test.appspot.com/
A message from John Furrier, co-founder of SiliconANGLE:
Your vote of support is important to us and it helps us keep the content FREE.
One click below supports our mission to provide free, deep, and relevant content.
Join our community on YouTube
Join the community that includes more than 15,000 #CubeAlumni experts, including Amazon.com CEO Andy Jassy, Dell Technologies founder and CEO Michael Dell, Intel CEO Pat Gelsinger, and many more luminaries and experts.
THANK YOU