Tag Info

Hot answers tagged

20

my years of software development experience suggest that in practice it can't work. Have you tried it? Dave and I wrote the book based on many collective years of experience, both of ourselves and of other senior people in ThoughtWorks, actually doing the things we discuss. Nothing in the book is speculative. Everything we discuss has been tried and ...


14

I take a different view from the other answers on here already. I agree with you that you want to integrate changes from developers as soon as possible, and to keep testing the combined mix of code. However, I do not agree that its right to ship code developed this morning, just because we are releasing this afternoon. That is a recipe for disappointed ...


10

First, CD takes one big mental adjustment -- you have to admit that sometimes things will go out broken no matter what you do. At the end of the day, you cannot prove a negative. Once you get past this, you realize that you need tools and procedures to a) catch these errors very quickly and b) either roll back or deploy the update very efficiently. ...


9

Your build number won't be reset to 0, when minor and major versions increase, this violates sections 7 and 8 of the specs: Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated. It MAY be incremented if ...


8

In short: Since you don't know whether a build contains a critical bug at the time of deployment, you may need to roll back more than one version when you're deploying at a relatively high frequency. If your setup doesn't allow you to do so, your only alternative is to roll forward as quickly as you can. As soon as you have an application that has 3rd ...


7

Continuous deployment or continuous delivery is very common in web services and SaaS apps. Amazon, Facebook, Github, Google...they're all deploying all the time. Some operators deploy a handful or even dozens of updates a day for each very narrowly-defined service. I'm not even sure you could easily count the number of deployment events massive shops like ...


6

There are two problems here: one is implementing half a feature; the other is keeping the shipping product working during continuous development. Implementing half a feature A strong overarching design will help with this. This lets you implement the feature with its boundaries clearly defined--e.g., APIs to adjacent bits of code, expectations about data ...


6

There are two differences between releasing on your own or releasing through Apples App Store: It takes 1-3 weeks to get approved for updates. Often one week, sometimes two, occasionally three. You run the risk of having your update rejected for one reason or another, thus having to redo the release again. Approving rejections is quick (1-5 days) So all ...


5

Disclaimer: I'm an unpaid advisor for their product advisory board. Zero Turnaround have very low cost products called JRebel and LiveRebel which solve a vast majority of the issues dealing with hot deploying WAR files to a web server such as Tomcat. As smp7d correctly mentions, JRebel is the development tool version of the two. They tend to work at the ...


5

Wikipedia gives pretty good summaries of most of these terms. Here is my take on them: Build automation is essentially automating how the software is built instead of manually invoking the compiler. This would be accomplished via tools such as Makefiles or Ant. Deployment automation is less well-define but involves taking your built software and ...


4

I'd suggest a two step process. Building creates the installer, which goes out to your server. The client machines are set up to pull the installer on startup/midnight/maintenance window and run it silently. So you continuously build throughout the day, but the live systems grab the new installer at the appropriate time. It's not so much a matter of having ...


4

So, for people following the first principle, at what point do you switch from debug to release builds? We switch early, when the source code got a version number and got pushed into the Debian build queue. We are in the lucky situation of doing scientific software with well-specified inputs and outputs and little system interaction, though, so the cost ...


3

Frankly, I think you should look at them all. Scrum because it heavily emphasizes iterative and incremental development. XP because it gives a lot of advice on the technical side of development. Kanban because it emphasizes WIP limits and flow. That's how I've come to know them anyway; I've noticed they've all influenced each other heavily over the years. ...


3

So, for people following the first principle, at what point do you switch from debug to release builds? As soon as we go to QA we switch to release builds. But when ever we build a release build our build process also builds a debug version of the dlls. This allows us to quickly drop the debug dlls into the QA environment and get additional information ...


3

Be aware of the annoyance factor of very frequent releases. It's one thing to update your web app daily, or even more often, so that users automatically see whatever small changes you've made since the previous release. But if a user has to take some action, however small, to install new updates, frequent updates quickly become tiresome. I've encountered ...


3

The short answer is: Do what works for your team. In a perfect continuous deployment scenario you might have this as a workflow: each commit (in a centralized system) or push/pull to a particular branch (in a decentralized system) would trigger the code to be built. If the build succeeds, that should trigger unit tests. If that succeeds, that should ...


3

There are some things which a CI environment can't effectively check. Or things which are cost prohibitive to implement in a CI build process. For example, I work with embedded systems which run on all manner of physical machines. It is incredibly difficult and frankly impossible to perfectly model the entire physical machine for all possibilities ...


2

In our environment, the code gets deployed at many sites. And hence there should be different context applied to each instance of deployment. Usually, we deploy it in a key "lesser risky" places and see the experience. This deployment still are in production hence, this is not 'debug' mode. But it also assumes that testing is done well. Of course, with ...


2

Release Early This is bit of an issue in case of Android/iOS Apps if your main channel of distribution and promotion is going to be Market/AppStore. If you release too early with some glitches (especially force-closes) you'll have some unhappy users. Just a few unhappy users can get your initial scores quite low, which will seriously hurt your chances ...


2

I'd like to debunk this "Apple's approval process is like running a gauntlet" business. No app I've ever submitted has taken more than seven days to be approved. In my experience, if you're careful and aware, you'll have no problem getting approved. Half a million apps or so have been approved, and my experience is, you really have to try to not get ...


2

A great example to look at/steal from is google chrome -- they do continious, silent deployment on Windows. Without requiring administrator approval. The main trick, as I understand is just using Microsoft Click-Once deployment combined with deploying to the %userprofile% rather than %programfiles% but I could be really wrong.


2

Given you've mentioned Windows Installer and MSI's, I guess you're mostly interested in deployment of client/desktop style apps? Automatically deploying to the build server itself should be relatively straightforward (by triggering a silent install as suggested by other posters) - for testing purposes this would only make sense for server apps (or in a ...


2

We have our developer machines set up to build debug builds. But once the devs commit code, a deployment package is created in our continuous integration environment (TeamCity) and that is built for release. So whenever we decide to deploy to QA, we take the latest deployment package from the CI server and push it out, so it is always release unless it is ...


2

Every system has risks, and every risk has potential costs. If the cost of some tiny risk, of the kind that may take months or years to find in extensive testing and QA, is high enough (the software in your heart pacemaker), you don't ship without an extensive period of testing of a frozen release. If the cost of failure is small enough, maybe you ship ...


2

You could restart Tomcat and be done with it. Also, Tomcat 7 has supposedly solved PermGen issues... although I haven't tried.


2

Msdeploy is the worst thing you'll ever to do to yourself. It is very very hard to get the IIS versions and configurations right for it to work as expected. I would definitely use something like 7-zip to zip the code and xcopy to copy it and of course powershell to remote to the box. You can then manage IIS using powershell commands. You could also try ...


2

I think Jenkins CI should help you to achieve what you want. You can also manage dependencies between different applications using pre/post build action plugins of Jenkins. Build Pipeline plugin should help you to manage the pipeline. The latest plugin allows "retry" which should help you to quickly revert back to the previous builds if you want to. I've ...


2

Many CI systems like teamcity or jenkins can be set up to monitor your version control system and kick off builds when checkins are detected. The sequence of events that is kicked off by the CI system often goes like this: If the build completes without errors, the unit tests run. If the unit tests complete without any failures, the build is deployed to ...


2

The best way to keep everyone in the loop is to have a set production deployment day/time on a reoccurring basis. Then you can send out a notification to all affected employees a list of all changes that will be implemented with the next deployment. This should be sent out well in advance of the changes being deployed (I would say at least an 8hr notice for ...


2

Multiple developer branches work just as well as a single branch - better in many cases. You might need to use a better tool for the job that TFS, but now it has git backing it that should do fine. I would not attempt to change the software architecture to suit your build process, its the wrong approach - the software is the thing that matters, keeping it ...



Only top voted, non community-wiki answers of a minimum length are eligible