Tag Info

Hot answers tagged

15

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 ...


12

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. ...


7

Not sure if you found this already, but looking through their wiki, they have a section of extending Jenkins, and a plug in tutorial.


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 ...


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 ...


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

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


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

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

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 ...


2

It's not "common sense" not to store credentials in source control. That really depends on your situation. It's a perfectly acceptable practice if the developers would already have access to production resources, or if the accounts are read-only and there's no privacy issue, or if the credentials are encrypted in some way. If you're going as far as building ...


2

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 ...


1

How do I make sure team members learn the right approach to implement half a feature? By teaching them. (duh) Learning will involve iteration: trying something, seeing how it works, and then modifying their approach to achieve better results. For this sort of thing, I would advocate design/code reviews. You get to see how the half-feature is ...


1

The biggest thing that will help you here is having a good separation of concerns so that as far as possible one area of code does not interfere with another. This is a place where using Dependency Injection and programming to the interface really helps, so that you can have your current implementation of ISupportingFeature on the site and then when you ...


1

Plenty of large enterprises are doing continuos delivery -- I'd think Amazon or Google would qualify. I think the conventional wisdom it runs into in large places is a wetware issue. There is some group that "owns" delivery and they are not going to like losing seats when you eliminate their manual testing routine and the black magic of a "deployment." On ...


1

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 ...


1

Works fine for us, but our customers are mostly internal. Multiple builds done during the day, broken builds are not tolerated, web start mechanism used so users get the latest version every launch. One thing is that CD makes a lot of problems go away. Yes, you have compatibility concerns all the time, however, since you're only deploying small changes ...


1

Full test coverage is impossible. You have to put in lots of time -- and time is money -- for every little thing. This is valuable, but the time could be spent contributing to quality in other ways. You don't need 100% coverage, you need enough to be confident in your system, that changes to one place won't break things you've previously proven ...


1

You should only be doing Continuous Delivery to a development server. Look at deploying changes to an exploded application on this server. If this isn't suitable increase the PermGen size. Schedule daily restarts of the server to clear the memory. Tag and build a deployment package for the Integration Server and only deploy when requested. This should ...


1

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 ...


1

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 ...



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