Where large development teams and codebases are involved, code modularity is a key enabler for continuous delivery. At a high level this shouldn’t be too terribly surprising—it’s easier to move a larger number of smaller pieces through the deployment pipeline than it is to push a single bigger thing through.
Lets define a true pipeline as being a pipeline that is strictly associated with a single revision within a version control system. This makes sense as ideally we want the build server to return full and accurate feedback for each single revision.
I am writing this blog to discuss how I went about iteratively testing my puppet module that was created to install the tool Blur.
Development Forges unify application development tools and promote collaboration, but they are often design and development time environments disconnected from run-time infrastructure. The next evolutionary step is Cloud DevOps Factories.
Developers extend their continuous integration platforms towards continuous delivery organically, deploying to dev test environments for simple functional tests. And later to QA environments using similar approaches.
GitHub, Inc., wrote the first version of Hubot to automate their company chat room. Hubot knew how to deploy the site, automate a lot of tasks, and be a source of fun in the company.
Here’s a few mistakes and anti patterns that I have come across when developers are using a continuous integration server.
Sometimes, small questions lead to big answers. Sometimes these answers are controversial. One such question is “What does this warning about serialVersionUID mean”? All the advice out there basically is for developers who don’t know what’s going on to write code that will ignore errors when something unexpected happens. In my view – this is exactly the wrong approach. The safe way to act is to make sure that your program crashes if you don’t have control.
The Devops movement addresses the dysfunction that results from organizations composed of functional silos. Thus, creating another functional silo that sits between dev and ops is clearly a poor (and ironic) way to try and solve these problems.
Learn about the fusion of contemporary Continuous Delivery processes and practices with the established and widely-accepted Maven release process.
I’ve fought the idea that DevOps is a job title, I’m nearly ready to concede defeat. Companies may not know exactly what DevOps is yet, but they know they want people with “DevOps” on their resumes.
On my current project we’ve been setting up production and staging environments and Shodhan came up with the idea of making staging and production identical to the point that a machine wouldn’t even know what environment it was in.
Here we will be taking a broader view of requirements, builds, deployments, provisioning, testing and monitoring.
Today I was setting up a second tomcat instance on a single Windows machine and was not able to run two instances at the same time. The first instance started fine, but when I went to start a second instance the second server would not start.
The theme for this conference was “Culture”. If DevOps is a “culture thing”, then surely we need to involve both Dev and Ops. The surprising part was that there did not seem to be anyone from the Dev side of things.
Tomcat has been around forever and hot deploy has never really worked. Found a hilarious thread with the two Hibernate cats laying out the reasons why, um, 6 years ago. Yes folks, this predates the iPhone.
When I work with customers who have even moderately complex deployments, they rarely deploy just a single build at a time. Usually, a collection of builds, updates and configuration is released in some coordinated fashion. Release manifests help with that coordination.
We’re using varnish to cache all the requests that come through our web servers and especially in our pre-production environments we deploy quite frequently and want to see the changes that we’ve made. This means that we need to purge the pages we’re accessing from varnish.
Going forward, I think the Phoenix server is the kind of model I actually want for our AWS deploys.
Like it or not, most of us, whether developers or sysadmins, work in a service industry. It’s fast and furious, and we don’t have time to build features that nobody wants. With sufficient test coverage, there’s no code that can’t be released within a day of pushing to the repository.
Chef is a great way to automate your cloud, and in particular its useful as your environment grows! On Engine Yard, Chef recipes can also be used to configure add-on’s (like Logentries) on your servers as we will explain…
Having trouble with those intermittent bugs that just won't reproduce on my machine; but will reproduce intermittently on other machines while they are running automated testing? Here's how Hudson/Jenkins can help.
I’m sharing my tmux PS1 prompt variable with you. It’s not the most advanced, doesn’t use all of the bells and whistles and I’m still not entirely sure the information it presents is essential but it’s a work in progress. I’d love for you to share your own in the comments in the hope of spreading know-how and ideas!
I’ve been having some intermittent DNS resolution failures on my recent installation of Ubuntu 12.04. Googling showed that I’m not the only one, and the solution found here seems to be working for me:
A goal of the deployment team is to help Java developers deploy their applications to their platform of choice. In some cases, there are multiple ways to do the same thing.