DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
Building Scalable Real-Time Apps with AstraDB and Vaadin
Register Now

Trending

  • Authorization: Get It Done Right, Get It Done Early
  • How to LINQ Between Java and SQL With JPAStreamer
  • Introduction To Git
  • Auto-Scaling Kinesis Data Streams Applications on Kubernetes

Trending

  • Authorization: Get It Done Right, Get It Done Early
  • How to LINQ Between Java and SQL With JPAStreamer
  • Introduction To Git
  • Auto-Scaling Kinesis Data Streams Applications on Kubernetes

The Power of Packaging Software: Package All the Things!

Learn how packaging saves time and space when attempting to achieve continuous delivery.

Kris Buytaert user avatar by
Kris Buytaert
·
Jul. 30, 15 · Opinion
Like (1)
Save
Tweet
Share
1.86K Views

Join the DZone community and get the full member experience.

Join For Free

Software delivery is hard; plenty of people all over this planet are struggling with delivering software in their own controlled environment. They have invented great patterns that will build an artifact, then do some magic and the application is up and running.

When talking about continuous delivery, people invariably discus their delivery pipeline and the different components that need to be in that pipeline. Often, the focus on getting the application deployed or upgraded from that pipeline is so strong that teams forget how to deploy their environment from scratch.

After running a number of tests on the code, compiling it where needed, people want to move forward quickly and deploy their release artifact on an actual platform. This deployment is typically via a file upload or a checkout from a source-control tool from the dedicated computer on which the application resides. Sometimes, dedicated tools are integrated to simulate what a developer would do manually on a computer to get the application running. Copy three files left, one right, and make sure you restart the service. Although this is obviously already a large improvement over people manually pasting commands from a 42 page run book, it doesn’t solve all problems.

Like the guy who quickly makes a change on the production server, never to commit the change (say goodbye to git pull for your upgrade process) if you package your software there are a couple of things you get for free from your packaging system. Questions like: has this file been modified since I deployed it, where did this file come from, when was it deployed, what version of software X do I have running on all my servers; are easily answered by the same tools we use already for every other package on the system. Not only can you use existing tools, but you are also using tools that are well known by your ops team and that they already use for every other piece of software on your system.

If your build process creates a package and uploads it to a package repository which is available for the hosts in the environment you want to deploy to, there is no need anymore for a script that copies the artifact from a 3rd party location, and even less for that 42 page text document which never gets updated and still tells you to download yaja.3.1.9.war from a location where you can only find 3.2 and 3.1.8 and the developer that knows if you can use 3.2 or why 3.1.9 got removed just left for the long weekend.

Another, and maybe even more important thing, is the current sadly growing practice of having yet another tool in place that translates that 42 page text document to a bunch of shell scripts created from a drag and drop interface, typically that "deploy tool" is even triggered from within the pipeline. Apart from the fact that it usually stimulates a pattern of non reusable code, distributing even more ssh keys , or adding yet another agent on all systems. it doesn’t take into account that you want to think of your servers as cattle and be able to deploy new instances of your application fast.

Do you really want to deploy your five new nodes on AWS with a full Apache stack ready for production, then reconfigure your load balancers only to figure out that someone needs to go click in your continuous integration tool or deployment to deploy the application to the new hosts? That one manual action someone forgets?

Imvho Deployment tools are a phase in the maturity process of a product team. Yes, it's a step up from manually deploying software but it creates more and other problems. Once your team grows in maturity refactoring out that tool is trivial.

The obvious and trivial approach to this problem, and it comes with even more benefits. is called packaging. When you package your artifacts as operating system (e.g., .deb or .rpm) packages, you can include that package in the list of packages to be deployed at installation time (via Kickstart or debootstrap). Similarly, when your configuration management tool (e.g., Puppet or Chef) provisions the computer, you can specify which version of the application you want to have deployed by default.

So when you’re designing how you want to deploy your application, think about deploying new instances or deploying to existing setups (or rather, upgrading your application). Doing so will make life so much easier when you want to deploy a new batch of servers.

Software operating system application

Published at DZone with permission of Kris Buytaert, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Trending

  • Authorization: Get It Done Right, Get It Done Early
  • How to LINQ Between Java and SQL With JPAStreamer
  • Introduction To Git
  • Auto-Scaling Kinesis Data Streams Applications on Kubernetes

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com

Let's be friends: