137

Normally you wouldn't just have a dedicated build machine, but also run a build server on that dedicated machine. A dedicated build machine merely offers the advantage of never blocking the work of a developer and deploying from a centralized machine. A build server offers much more. A build sever allows for CI (continuous integration), meaning that it ...


107

In addition to Traubenfuchs' answer, you have hinted at another reason for a build machine in your question. Just because the software builds on your machine, it doesn't mean that it will build on anyone else's. You may be relying on some random files that just happen to be on your machine (and may not even be under version control). You may be relying on ...


103

Which is best practice? to manually deploy one project artifact each deployment or keep doing the file by file deployment? Neither. Best Practice is to automate your deployment, completely and exclusively. That means nobody gets to put anything onto a server manually. "To summarize the summary of the summary: People are a Problem." (Douglas Adams) ...


85

Not at all. Imagine you're running the version 1.8.0 of Java on both your development machine and the server. By the way, you're working simultaneously on two projects, both using Java. One day, a bug is found in JVM, and the servers which run the first project you're working on are migrated to 1.8.1. By the way, the servers running the second project aren'...


53

The main reason for having a dedicated build machine is to get consistent builds regardless of who is doing the build. Developer workstations are rarely (read: never) identical. It's hard to know that each build is using the same exact versions of dependencies and compilers etc. One of the worst problems with dev workstation builds is that developers can ...


53

This question is really two questions in one. Todo comments Of all the ways to track action items, this is the worst. TODO comments are good during active work or as a way of suggestion to a maintainer, "here is something that could maybe be improved on in the future". But if you rely on TODO comments for getting work done, you're doomed to fail. What ...


44

Build an SSCCE (short, self contained, correct example). If the bug disappears when you remove some of the extra details for the SSCCE, then you found it. Otherwise you will have an SSCCE that you give or post that ideally eliminates the code that you are concerned about sharing.


35

You rarely just deploy a "Java App". Your java application has a lot of different support programs around it. We use Apache HTTPD, Apache Tomcat, ActiveMQ for messaging, an FTP Deamon, MySQL and a handful of custom services to integrate with programs that don't work directly with Java. This doesn't even go into the development software that goes along ...


30

There are a few obvious arguments against this. What happens if you leave. Is all this information carefully documented, or is it mostly in your head. Automated scripts are a much better place for someone else to take over from. Everyone makes mistakes. There will come a time when the person doing the deployment is tired, not paying attention whatever. ...


28

Two things: Staging environment, as similar to the live environment where you do test deployments. Ample testing of this environment after deployment. Automated and non-automated. There are other things that can be done. I suggest reading the 5 part blog series about automated deployment by Troy Hunt. The tooling he uses is MS stack specific, but the ...


24

Do not use TODOs. You already have a TODO list in your project. It's called the issue tracker. I think the real problem is in this sentence: we can create a ticket in our issue management system, which creates clutter and also might get moved to a later sprint or the backlog by management. If your issue tracker creates to much clutter, find ways to fix ...


22

In layman's words: Not all users use all of a company's apps Different users have different needs Why force an user to buy a full package when he/she needs only a part ? (Ok, Google apps are free, but other software maker's aren't.) Having those apps separate makes it possible to be updated separately and, most importantly, sold separately. The fact that ...


21

You can get the best of best worlds: peace of mind with process verification and the reliability of automation. Script the deployment. Then, go through and manually verify that processes are started, files removed, etc. In other words, write your own QA script just to verify that automated steps 1 - X actually occurred.


20

The best practice is to have an approximation of the production stack on your local developer machine. This typically includes the database, web server and your customized code. Do all of your development there. Never edit code on a production server. When your business stakeholders are ready for the functionality to go live, push your code from your local ...


20

An installer always makes sense, if deployment requires anything more complicated than copying the relevant file(s) to some folder and running the EXE. If there are additional steps that need to be taken to set the product up properly, there's two ways to go about it. You can write out a list for someone to follow. Humans being humans, someone's bound to ...


19

The other answers quite correctly noted that you should automate the build, which means it isn't necessary to walk to another office. However, let me propose a certain number of steps you could take to improve your build process: Firstly, set up remote access to the build server! If you build manually by typing the command "make", this means you don't have ...


18

No. Source control should only contain source. If it's generated from source, it doesn't belong there - and should be generated by your build process. The fundamental reason you don't want to source control intermediate build artifacts is that if you do, it gets really hard to trust wether what you're running comes from the source you just modified, or ...


16

I really don't think its a huge complexity for the end user to have to select either a 32bit or 64bit option when downloading. But if you can use the user-agent strings to make a suggestion all the better. Another option is to have your installer detect and install the correct binary for the user's platform. That makes for a larger download, but then the ...


16

... instead of getting an actual machine in our office to use, we're having to share a single machine with several other groups ... You say that like it's a bad thing. You now have a common build server that all of your builds - yours and the other teams' - are built through. Consistency of build? Check. ... the hassle of having to leave my office ...


16

Why not? Any of the things you describe would be a problem whether you use continuous deployment or not. The problem, it seems, is that you are worried the juniors will make a catastrophic mistake. And that that mistake will be rushed into production before anyone can catch it. That's why you do code reviews and do testing. Before anything gets merged ...


15

I'm not a big fan of them, but several reasons come to mind: It allows them to more easily deliver the most recent build to the customer. It allows them to speed up the download by only delivering to the user the pieces they want to actually install. Huge downloads via HTTP often stall out. A download manager allows for a smaller initial download, and ...


14

I think the key here is: why do you think that you can't script the verification process? My deploy scripts don't just push archives and restart services. They print out lots of color-coded information during each step of the deploy, and provide me a summary of events at the end. It lets me know that processes are up and running, that the homepage is ...


14

This is a very pragmatic approach to database-backed software upgrades. It was described by Martin Fowler and Pramod Sadalage in 2003 and subsequently written up in Refactoring Databases : Evolutionary Database Design. I can see what you mean when you say that it seems sloppy, but when done intentionally and with forethought, and taking the time to refactor ...


14

Manual steps take a lot of effort and are risky: you might forget a necessary file. Maybe not everyone in your team knows which files need to be copied. All of these issues make deployments big, daunting, and rare – completely unnecessarily. Automation addresses these. Even the simplest automation step can have big benefits, because deployments become ...


13

I wonder, why no one mentioned Version control -- which is one of the most important ways to save you from trouble while updating/upgrading. First, your deployment should be just a clone of the stable branch on your repository. Everything including config files, SQL files, install/update scripts MUST be version controlled. Second, you need to have "some ...


13

While what you have done is sure to be a good thing, the project manager has to worry about a number of things: testing - what if you break something. Either something in the home page, or some other unintended consequence? The system needs to be retested. Depending on how far your company goes, this could be a large cost. Scheduling user downtime. May be ...


13

"It depends." For normal development tracking, no. For cloud and DevOps deployments, however, it's often convenient, or even required. Most of the time, @ptyx is correct. Indeed, his "no" could be stated somewhat more emphatically. Something like "No. No! OMG NO!" Why not store minified or compressed assets in source control system like Git? They can be ...


13

A version number is a minimal hindrance to an attacker and a great help to defenders. Frequently, attackers will just try an exploit without bothering to check a version number. I get several windows-based attack attempts per hour in my snort logs, and I haven't owned a windows machine in decades. The exploit working is the only confirmation they need. ...


13

Git is not suitable for managing different variants of your code. Git is not a deployment mechanism. Git is just a source code management system. One thing that gets lost when using git push as a glorified FTP command is that source code is source code, and not necessarily the same thing you deploy. That even holds for interpreted systems where the ...


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