Hot answers tagged

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


22

It sounds like you have a few problems here: 1. Identifying features for a specific release This is a project management issue, and a coordination issue. Will this feature be released before, at the same time as, or after this other feature? If releases want to happen one feature at a time, then identify that. If features are going to be grouped into ...


19

The main reason is the cloud. It used to be that your code got shipped on floppy disk, and then CD, and then it got deployed to a server, and then it got deployed to two servers (for resiliency)... And all of that deployment could be manually done by a human, so humans were trained in doing it. Today, your code is often going to dozens or hundreds of ...


15

There are lots of different reasons for various organisations to move to DevOps. I'll try to list the ones that come up often. Reduce time to change cycle There is often a long time between making a request for change and it actually being deployed and used in the organisation. First it is planned in one of the development cycles by the developers and after ...


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


12

The situation looks pretty simple to me: people need the tools to do their job correctly. If they need root access, they should be given root access and they should be trusted (and trained, if necessary) to use it responsibly. Similarly, if they don't need root access then there is no reason to give it to them.


12

I think this is probably best described by stating the bad practices it would seem to be trying to avoid. I can remember the old days when these were common practice. But with modern 'dev ops' tools being so easy to use these days I doubt they are seen anymore. Live code fixes. (Run and Build stages are joined) A bug is reported, I fix it on my dev machine,...


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.


9

I write some code, then I build it (compile it) then I run the tests. This happens on my local machine. That's the "code & build" phase in that diagram. Then I check my code in to a central repository, triggering a remote build and remote testing. I have now performed a "doesn't just work on my machine" test. I've "integrated" my code into a central ...


8

Be careful! Without proper guidance from technical leadership, DevOps "teams" can end up being janitors, responsible by default for any/everything that isn't explicitly someone else's responsibility already. As Jez Humble has stated, DevOps "is a practice, not a tool.", with one of the driving motivations being to reduce silos between engineering, QA and ...


8

Don’t shoot… I come in peace ;) I can relate to the other side of the coin as I used to be one of those Operations People. Just imagine that you(the Dev) are being pulled into Operation meeting where there is nothing for you to say or relate to and you have to sit there for a number of hours. And the only thing you can think of is you backlog of BAU ...


7

You could rename the directory to a new name and create a new empty directory by that name, both steps under the same lock (e.g., by locking the parent directory, but that depends on your specific file system). Then release the lock and empty the renamed directory. IMHO using this method you should be able to skip the renaming of each individual file.


7

Terms like DevOps are subject to the whims of enthusiastic marketing and consultancy folk and all too quickly become "must have" buzz words. But underlying it is a simple concept: infrequent, "big bang" integration, testing and development are expensive, time-consuming processes that generate antagonism between teams. Further, unless developers are ...


6

While root/admin access to the machine may be useful for setting up the environment, tests should be run in a way the "normal" user of the product does. In most cases, this will mean that a "normal" user account should be used (that does not exclude an additional root account for setup/configuration). If the system under test has its own user rights ...


6

One method to identify the most important bottlenecks is to make it visible what stages the work items go through. As a start, try to follow a couple of work items (new features, bugs, improvements, etc.) through the complete cycle from the item becoming known to the team until the point where it has been successfully deployed into production. Write down ...


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


6

Lets start by separating out a few terms: DevOps A movement to bring Development and Operations together to help break down the barriers between departments and share skills and knowledge. Closely linked are: Continuous Delivery The continuous delivery of value. This is often managed as part of something like a scrum framework to constantly add business ...


6

The role of DevOps is to enable self-sufficiency among developers, not to take on all of the work yourself. I believe you are right in encouraging developers to use feature toggles but unreasonable in limiting them to only two branches. Feature toggles work well for new features that don't overlap with other features, but you'll eventually get into a ...


6

Some things like DevOps really are just buzz words, and even groups that don't do "DevOps", really do indeed do large chunks of it. For example: do you have a code repository? Do you run unit tests before promoting code? Are your deployments automated? There are many more. A lot of this was already happening before DevOps simply gave a name to it. So ...


5

The primary advantage of Docker is the ability to create wholly deployable applications as build artifacts. The deployable applications can be run through test suites that verify that they operate correctly before promotion as production images. This differs substantially from install scripts because the testing is done before production and less is ...


5

You have to explain two things in order for a new technology / paradigm / language / methodology / whatever to have any chance of success in a team. First, you need to explain what is not working with the current approach. You then need to explain how your proposed technology would solve those problems, while not introducing any bigger problems (that you ...


5

Load Balancer For the second point, use a suitable load balancer. You can shift a portion of the traffic across, first to prove the new deployment, then to slowly ramp it up. It also allows a quick backout strategy. Database versioning There are two ways to go about this: Make the Authoritive Data-form (the SQL schema) backward compatible between Green/...


4

Here's an idea, Stop using release branches. Instead, start building in feature toggles and manage it via configuration. That way, you're always merging feature branches into master and there should never be a question about what version is in test or prod. If you have a question about what features/implementations are active in an environment, just check ...


4

If you're not using a build server then the simplest option is to put it in the config files. This way they're not embedded in source control. Think of database passwords, these are "private keys" too at the end of the day, and are commonly stored in config files. They aren't directly readable by a hacker either, unless they have access to your server -- in ...


4

If you're working in a structure like this, how do you establish what to prioritise, what to defer? The same way you prioritize anything else: you always pick the action that maximizes the benefit over cost. If there's a bug that has an easy resolution that lots of users are running into, fix that first. If there's an exciting feature on the horizon that ...


4

It sounds like you need a package management system. There's several available depending on the platform you are working with (NPM, Maven, Nuget, Chocolate, etc.) TFS has built in support for hosting Nuget packages, and Visual Studio 2017 makes creating Nuget packages for .Net Standard and .Net Core apps very easy. However, if you have a heterogeneous ...


3

So if I understand correctly, the approach of your team is to create binaries initially, then push to test, preproduction, and eventually production with those same binaries, and the approach of the other team is to use branches to reflect the various environments and perform continuous builds from those branches? Consider that while I agree with you, as ...


3

Facing a queue of two tickets, or ten tickets, or one hundred tickets, the application team has to decide what to do first. I'd argue that it's not the applications teams' job to do this except in a very low-level tactical way e.g. "Critical issue, drop everything now." "We'll do these two bugs together because they're in the same module." "We'll fix ...


3

If you use some kind of service orchestration tool like Kubernetes it's easier: Kubernetes helps you mount secrets into containers savely: http://kubernetes.io/docs/user-guide/secrets/


3

This should be a simple matter of coordination between test and production. If you're using feature branches in Git, simply stop pushing completed feature branches to Test during a testing cycle, and resume when testing is complete. If you need better control than this, separate Test into a Development server and Acceptance Testing server, and coordinate ...


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