26

The company I work for now doesn't implement continuous delivery yet. We still deploy the project manually to server, file by file. Which is best practice: to manually deploy one project artifact for each deployment or keep doing the file-by-file deployment?

Improve this question
5
  • 12
    There isn't even remotely a "one practice for all situations" for this task.
    – whatsisname
    Oct 13, 2017 at 1:18
  • 26
    Normally I would link to Why is asking a question on “best practice” a bad thing? I think we can all agree that this is worst practice. It ranks slightly above "setting fire to the server."
    – user22815
    Oct 13, 2017 at 3:28
  • 3
    relevant: en.wikipedia.org/wiki/…
    – Jens Schauder
    Oct 13, 2017 at 10:35
  • 9
    I suspect that OP is asking this question because he already knows the answer, and his workplace is Doing It Wrong(tm), and OP is trying to garner evidence to make a case for changing the way they do things.
    – user1936
    Oct 13, 2017 at 13:55
  • 2
    We did it this way in the second millennium. Should be fine! ;)
    – Don Branson
    Oct 13, 2017 at 19:01

7 Answers 7

Reset to default
105

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)

People make mistakes. If one of the files that you forget to copy across is a shared "library" that's been extensively changed, you can bring the whole Production site crashing down.

Improve this answer
10
  • 17
    @JohnHamilton If automizing compilation is a difficult task, then that itself is something to resolve in the long run. You don't have to have development, test, preproduction environments complete with completely automized deploy, but the creation of a standard deploy package should be standard practice.
    – Neil
    Oct 12, 2017 at 12:11
  • 20
    Er, the size of the company isn't really the issue (to a degree). The cost is going to be related to the extent that the deployment is automated and also related to the complexity of the production environment. But there's a gradient of automation and gradient of "cost" (time/money) starting from simple things like a script to copy build output onto production (small investment with immediate tangible cost savings), and ramping up from there, and it's more dependent on management buy-off than company size.
    – BurnsBA
    Oct 12, 2017 at 12:18
  • 39
    @JohnHamilton: A smaller company that's poorly managed might delude themselves into thinking that, sure. Automating copying files isn't exactly a difficult task, and the cost of having any employed person do this regularly will vastly outweigh the cost of writing even the most trivial script to do it instead.
    – GManNickG
    Oct 12, 2017 at 18:34
  • 8
    @JohnHamilton: The cost of automation has to be weighed against the risk of mistakes made during manual deployment.
    – Robert Harvey
    Oct 12, 2017 at 20:40
  • 7
    You don't even necessarily need Jenkins. Just a checked-in script with a bunch of scp commands (or whatever you use when manually uploading) would be an improvement.
    – user253751
    Oct 12, 2017 at 22:00
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 trivial. A script that copies the files or artifacts via (S)FTP or Rsync or another technology is a great first step. You can later expand that script to perform pre-deployment and post-deployment steps on the server automatically, like restarting services.

Improve this answer
3
  • If the total number of servers is 2 or less, manual is less risky than automatic. Automatic requires extensive bug-checking. I've never seen a trivial automatic solution that stayed trivial.
    – Joshua
    Oct 14, 2017 at 15:13
  • 4
    @Joshua I'm not sure the number of servers should be a factor here. Automation also has value when you deploy to the same server multiple times. The question is, who do you trust more: the computer to faithfully execute a script that worked once, or your ability to remember all necessary steps each time? As a fallible and forgetful human, I have a strong preference for not doing stuff manually. Sometimes I even script one-off tasks just so that I can review the commands before running them. That is a lot less risky than doing random stuff manually until it works!
    – amon
    Oct 14, 2017 at 19:27
  • I have extensive experience both ways. The stuff I make for manual deploy is xcopy install so there really aren't steps to forget some of.
    – Joshua
    Oct 15, 2017 at 3:00
9

Best practice would be to implement an automated process of some sort.

Be careful to check that there isn't a special reason for the 'file by file' approach which you would have to take into account.

Improve this answer
4
  • 1
    I ask this question because I just want to make sure that it's totally not best practice in the world. I wonder is there still any company/developers who still manually deploy their apps/project, and what make it worse is file by file deployment each iteration of development.
    – Jake Muller
    Oct 12, 2017 at 10:30
  • 4
    The best question to ask is "why do we do it this way?" I cant think of a reason, but I do know that some companies like to keep a manual hand on the trigger as it were
    – Ewan
    Oct 12, 2017 at 10:34
  • 8
    @JakeMuller What you should read between the lines of this answer is that decisions should be made by reasoning about the situation, not slavish adherence to what somebody with no knowledge of it had declared to always the right answer.
    – Blrfl
    Oct 12, 2017 at 11:54
  • The reason for the file by file approach could be that are dependencies between the files and so file updates are deployed before the changes to other files that depend on those files. Updating the files in the wrong order might briefly brake the system.
    – bdsl
    Oct 13, 2017 at 11:34
6

With Continuous Delivery (or Deployment, actually) and moving each file by hand, you're looking at the two extremes. It's perfectly understandable that you can't/don't want to create a fully automated pipeline (yet). However, you should consider automating parts of the process.

Moving each file by hand is quite risky, and you could mitigate that risk by, for example, tagging your code repository, checking out that tag in your computer, building your artifacts and uploading them to your server. Each of these steps can be automated so that they're executed with a few mouse clicks, and this will greatly reduce the risk of forgetting a file or accidentally pushing to prod some extra files.

Automate what you can, once step at a time. The fact that you can't afford a fully automated CD pipeline shouldn't discourage you from automating some parts.

Improve this answer
1

Best practice would be to do a cost/benefit analysis for your particular deployment for your particular company.

The general answer is "don't do things manually, automate." This is generally the right answer for general sorts of companies. The uniformity of the answers you are receiving should be some indication of just how strongly the community finds this to be best practices. If your company feels that automation is not the right tool, they should have some understand what makes them unique. That uniqueness should be factored into your decision making process. There is no "best practices" when the sample set is 1.

Questions such as "how many files" and "how often are things updated" and "what are the consequences of breaking things" and "how quickly can you roll back a bad change" are important questions to answer. If you automate, many of these questions become unimportant, but they are essential for properly assigning the costs and benefits for a manual update process.

Improve this answer
1

There are plenty of shades of grey in between manual file-by-file copy and continuous delivery.

Start by reducing the complexity of the deployment process, for example by using a zip file, an rpm style packaging, an infrastruture as code management tool (such as puppet or chef) or even just a simple script which copies the files for you from a staging area on the ftp server.

Deployment processes with more manual steps are more likely to have errors (and thereby fail) - like others have said, take the human element out of it.

You don't need to implement full continuous delivery (which is costsly, and takes effort / investment / innovation over time) - start simple, make it work, demonstrate the benefits - and go from there.

Improve this answer
0

It depends on the software technology (or stack) you are using (interpreted language, compiled language, desktop app, mobile, etc.), soft. dev. department policies, if you have the tools to automate it, how critical is your app, and one important thing to consider is your software architecture (how your app was designed). This is why you have here different answers. As a rule of thumb, the best approach will be to reduce as possible human intervention in deployment tasks, to avoid mistakes. A good practice will be testing everything in a QA Server (consider using a virtual server if budget is an issue) before deployment, and having reverse procedures to restore to previous version in case of disaster (ALWAYS have a backup).

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.