DZone
DevOps Zone
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
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > DevOps Zone > What Developers do Today for Source-to-Deploy is Not Enough

What Developers do Today for Source-to-Deploy is Not Enough

Carlos Sanchez user avatar by
Carlos Sanchez
·
Feb. 16, 12 · DevOps Zone · Interview
Like (0)
Save
Tweet
7.91K Views

Join the DZone community and get the full member experience.

Join For Free

developer toolset

from the developer point of view, there are some tools involved in the source-to-deploy process

  • source control management tools: subversion, git, mercurial, perforce,…
  • build tools: maven, ant, ivy, buildr, graddle, rake,…
  • continuous integration tools: continuum, jenkins, hudson, bamboo,…
  • repository (artifact) management tools: archiva, nexus, artifactory,…

the #1 programmer excuse for legitimately slacking off: my code is compiling

when everything is set together, we can have a ci schedule that is building automatically the changes from the scm as they are committed, deploying to an artifact repository the result of the build or sending a notification if there is any error. everything fully automated. a change is made to scm, the ci server kicks in, builds and runs all sort of tests (unit, functional, integration,…) while you go off for a sword fight with your coworkers.

now what? somebody sends by email the tarball, zipfile,… to the operations team? oh, no that would be too bad. just send them the url to download it… and even better send some instructions, a changelog, upgrade task list,…

what developers do today to specify deployments and target environments is not enough.

the simplest solutions are often the cleverest. they are also usually wrong.

using tools like maven in the java world or bundle in rubyland you can explicitly list all the dependencies and versions you need. but there are some critical dependencies that are never set.

it is just too simple.

packages installed, c libraries, databases, all sort of os and service level configuration,… that’s the next level of dependencies that should be explicitly listed and automated.

for example, think about versions of libc, postgresql, number of connections allowed, ports opened, opened file descriptors limit,…

operations

requirements

from the point of view of the operations team the number of requirements is complex: operating system, kernel version, config files, packages installed,…

and then multiply that for several stage configurations that most likely won’t have the exact same configurations.

  • dev
  • qa
  • pre-production
  • production

deployment

deployment of the artifacts produced by the development team is always a challenge

  • how do i deploy this?
  • reading the documentation provided by the development team?
  • executing some manual steps?

that is obviously prone to errors

cloud

it’s nothing new but it has increased with the proliferation of cloud based environments, making it easier and easier to run dozens or hundreds of servers at any point in time. even knowing how to deploy to one server, how is it deployed to all those servers? what connections need to be established between servers? how is it going to affect the network?


source: http://blog.carlossanchez.eu/2012/02/16/devops-how-we-got-here/
dev source control CI/CD

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • MEAN vs MERN Stack: Which One Is Better?
  • Python 101: Equality vs. Identity
  • Version Number Anti-Patterns
  • Artificial Intelligence (AI) And Its Assistance in Medical Diagnosis

Comments

DevOps Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • 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
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo