18 ms·
How to Deploy Software
- ngrilly 11y agoThe post is interesting, but it doesn't mention two major difficulties: zero downtime deploys and database migrations.
- herge 11y agoWe use django migrations, and I still haven't found a way to do zero downtime deploys and migrations short of doing the following: If we are trying to deploy migration #1, first deploy a version B of the code that supports (but provides the same set of features as before) the db both after migration #1 and before migration #1 (maybe with the help of a feature flag that is set in the migration). Do the migration. The deploy a version C of the code which removed the feature check above. But all this requires 2 different versions of the code and a lot of process just to ship out one migration. It gets combinatorically worse if you have more than one migration to deploy.
- mwarkentin 11y agoYep - unfortunately that seems to be the only way to handle it though.
- raziel2p 11y agoI wish there was a way to "pause" incoming requests in web servers. Most deployments (migrations + code) take less than a few seconds, and I'd be fine with some users having to wait 2 seconds for a request to finish over their request hitting a 500 (due to inconsistent code/database) or 503 (putting the site into maintenance mode).
- acdha 11y agoOne approach which can work pretty well in many apps is having something like a CDN or Varnish which can serve stale content when the backend is unreachable. That allows the code you need to bootstrap your app to be served as long as your edge cache is running and your JavaScript can some sort of retry+backoff for failed requests or even do things like check for image error states to trigger a reload.
- tmedbury 11y agoLoad Balancers.
- sciurus 11y agoHave your load balancer drain connections to a web server. When it has no request in progress, deploy to it. When that's done, move on the the next web server.
- tpg 11y agohaproxy allows re-dispatching failed requests some number of times. If you have an extremely brief outage due to a deploy, redispatching failed requests 3 times may be sufficient. I imagine other load balancers have similar functionality.
- wvenable 11y agoUsually we aren't deploying a schema change that's really huge so we just go for it and let the application crash for those users who happen to hit a place where the code/schema are out of sync. Zero (no crash) downtime deployments seems like too much effort for too little gain.
- AznHisoka 11y agoAgreed. Seems like a case of optimization for technical completeness rather than a business need.
- kl4m 11y agoBasecamp apparently uses an nginx/openresty plugin to pauses requests during a deployment: https://github.com/basecamp/intermission https://github.com/basecamp/intermission
- netghost 11y agoFolks from Braintree gave a talk about how they did this. They'd queue up all the incoming requests in Redis, then replay them once the site was back up.
- duggan 11y agoThere is, sort of. If you're hosting on Linux, you can use iptables to artificially delay responses. That and some other methods are described in a post on the Yelp engineering blog[1]. 1: http://engineeringblog.yelp.com/2015/04/true-zero-downtime-haproxy-reloads.html http://engineeringblog.yelp.com/2015/04/true-zero-downtime-h...
- sciurus 11y agoI don't think that's quite what raziel2p wants. Won't that still allow the web server to receive and process the request, but just delay it's response?
- jsmeaton 11y ago(I think I'm just expanding on what you say you already do - but I'd already written it out by the time I realised that this was exactly what you are doing, so I'm going to just leave it). If you can, always make migrations backwards compatible with the previous version of the code, so they don't need to be rolled back if the code needs to be rolled back. Having a good migration rollback procedure is nice too, but usually unnecessary if testing has gone well. If you need to add a new field to the model then always create it as nullable, whether or not you use a default value. That'll allow this particular database migration to run on previous versions of the code. You can test this by generating the migration SQL and running it on the database for your test/dev environment which is running your current production code. Once the new code and migration is running in production and you're satisfied with it, immediately create a new change which makes the previous migration more strict (remove nullable, use a data migration or default value for existing nulls). Test, stage, deploy that. Having backwards compatible migrations leads into zero downtime deploys also. Once the data migration has run, your app servers can be running version X or X-1. Before you push new code to a node, do a graceful shutdown (allowing queued requests to complete) or remove the node from the cluster (haproxy socket api for example), update the code, bring the node back into the cluster. Caveats: - not all database migrations can be backward compatible, but most can be made so by breaking your change into two or more changes. First - make the change without strict integrity checks. Second, enforce integrity checks and provide defaults. - zero downtime deploys requires multiple nodes (counter example would be welcome, but I can't think of one).
- bhuga 11y ago> and a lot of process just to ship out one migration. I would have agreed with you before working at GitHub, but the end result is that deploying is so easy that 3 deploys does not feel like "a lot of process." On most of our applications I can do this in 15 minutes or less.
- holman 11y agoYeah; I tried to stay away from really low-level aspects (just because they're hard to generalize across languages), and also just because the damn thing was so long already, ha. :) As far as database migrations are concerned, GitHub (and others, of course) takes the perspective of migrating before the code that uses those migrations go out. In other words, as @herge says in a sibling comment, the code that gets pushed needs to support two branches of code and two branches of data simultaneously. It's certainly some extra work (and can be pretty gnarly depending on the scope of the migration), but once you get to a certain point it's kind of the only way to do no-downtime migrations. There's many possibilities to help with the actual migration process, depending on what database you're using. With MySQL, for example, you can do something like the process in lhm: https://github.com/soundcloud/lhm https://github.com/soundcloud/lhm Zero-downtime deploys aren't super difficult in Rubyland anymore (many have written how they achieve it in Unicorn, for example), although I'm not as familiar with how other folk do it across other languages and platforms these days.
- heavenlyhash 11y ago+1 -- treating the database and the backend as two separate services with their own release lifecycles and APIs is "obvious"... ...well, once someone says it out loud. :) After that, of course it makes sense that they would have a need for an API compatibility window across at least two versions. It's exactly the same issues as supporting a backend and client side where you can't instantaneously force an update to all clients. With your DB, you're in control of the version, but you're certainly not in control of making it "instantaneously", so the same rules apply as when you're waiting for some curmudgeon user to update: API versioning and a support window. Now, if only we had an automagic way to make it less painful for a project to support two different versions of an API from the same codebase....
- mrighele 11y agoFor the part regarding database migrations, you can find here [1] an interesting podcast about SQL database (schema) evolution. Among the other things they talk about how to have multiple schema revision coexisting at the same time. While hopefully most of us just need to support at most two revisions at the same time, it gives a number of interesting ideas. [1] http://www.se-radio.net/2012/06/episode-186-martin-fowler-and-pramod-sadalage-on-agile-database-development/ http://www.se-radio.net/2012/06/episode-186-martin-fowler-an...
- lucaspiller 11y agoOne thing this glances over is that you should have something monitoring your production systems to make sure that they are running correctly. To start with get something to monitor errors/exceptions and email you. To name a few services: https://airbrake.io/ https://airbrake.io/ https://rollbar.com/ https://rollbar.com/ https://github.com/errbit/errbit https://github.com/errbit/errbit (can be hosted on Heroku for free) Also make sure that you have accessible logs that log useful information (timestamps, the user making the request, unique request ID). Then use syslog or a SaaS service to aggregate logs from all servers in one place, and keep them for as long as you can.
- mwarkentin 11y agohttps://getsentry.com/ https://getsentry.com/ is another option (my favourite) for exception monitoring.
- nicko84 11y agoI'd also add https://raygun.io https://raygun.io as great option here. Those services are more for the DIYer / startup market but if you need a professional error monitoring tool I recommend you check out Raygun.
- detaro 11y agoYou are a raygun employee? If yes, please disclose that if you "recommend" a product.
- blowski 11y ago> Deploying major new features to production should be as easy as starting a flamewar on Hacker News about spaces versus tabs Great writing. Spaces all the way.
- felixmc 11y agoWould someone mind explaining the argument for spaces over tabs? Possibly naive young dev here.
- sdegutis 11y agoSpaces work better with my preferred IDE setup. Therefore spaces are inherently and objectively superior to tabs.
- andrezsanchez 11y agoI personally like the idea of tabs better, but prefer spaces because it makes navigating the text less awkward when traversing tabs. It may sound stupid, but for my own stuff it's just more comfortable.
- ktRolster 11y agoHow many spaces do you like to indent your code? Some people like 3 space indentations, some like 8 spaces, and some like 5. It's very personal (but anyone who doesn't use 3 is a reeky brazen-faced mammet). A simple solution is to use tabs, because then every developer can set the tab distance however they like, and they are happy. It breaks down when you have code that is aligned beyond the indent, like this: if(a && b && c && d && e && f ) { In that case, increasing (or decreasing) the tab distance will ruin the intention. The best solution is to use tabs to the point of indentation, and then spaces thereafter, but a lot of code editors don't support that, so in practice it's hard to implement, so people use spaces to preserve their formatting when it gets uploaded to github.
- pcora 11y agoOMG! 3 spaces? EVEN number? 2 or 4. Never even.
- rb808 11y agoDoes anyone else work on systems that take 3 hours to back up the DB, an hour to deploy, 1 hour to start up and a few hours for users to check out functionality before business opens on Monday? No to mention the federal regulations about what paperwork is required and who can even access production. Maybe I'm in the wrong site.
- RandomChance 11y agoHah, we (hopefully!) get an update window every 18 months! And a staging a new production like test environment starts with another $100K invoice.. And thank goodness Microsoft hard-coded in a 10 hour delay to ensure the KDS root key of a domain is propagated, even if I create it before I create additional domain controllers... Such fun!
- tumba 11y agoOff topic, but to create an immediately effective KDS root key, just set the effective time ten hours in the past. You can validate propagation by looking for the 4004 event in the KDS event log. This is probably not a good idea in production, but is useful when building/rebuilding a lab. Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10)) See https://technet.microsoft.com/en-us/library/jj128430.aspx https://technet.microsoft.com/en-us/library/jj128430.aspx
- henrikschroder 11y agoLuxury!
- sz4kerto 11y agoHear, hear. I don't have any access to production. (Interestingly, that's just one more reason to fully automate stuff.)
- jventura 11y agoNo federal regulations or 3 hours to backup the DB, but in my previous job we had to build a deb package on a build server, then copy the package to the repo server, and finally ssh into the test/preprod/prod server to do the deployment (using sudo apt-get update). And I didn't have access to the production servers..
- my5thaccount 11y agoI just double-click a command file on my desktop and I'm done.
- kelvin0 11y agoIn theory, feature flags seem like a good idea. Until you reach a point where too many flags become difficult to test in an exponential tree of combinations. Also, it demands tight discipline to make sure each new flag properly isolates some new feature ... Has someone had success with this idea, and be able to 'tame' an explosion of flags in their codebase? really curious
- holman 11y agoI can't speak to them now, but it happened a number of times while I was at GitHub. We'd have a number of things staff-shipped for weeks or months (occasionally a year!) and it was just... there... and nothing happened much to it. As you might expect, it wasn't really the fault of feature flags but rather indicative of a process problem. We'd either have to prod the team or person in charge of it, verify that work was actively pushing things forward to ship, and so on. At various times we'd have, for lack of a better phrase, the "No (wo)man", who would come in and say "no" to a lot of things. One of the best ways to achieve this is to see that nothing has happened on a feature flag for awhile and then send a pull request to remove the feature flag (and the feature entirely). This got people out of the woodwork who said waiiittttt a minute let me just finish that up, or if no one vehemently disagreed with the pull then you could actually just remove it entirely. But it did take some explicit reflection on whether the flags were defensible to remain flags.
- ktRolster 11y agoI'm interested that you're having a problem with this, but you don't give much detail. Why do you have so many feature flags at a single time? Do you have a team of 20-40 people or more? Are your features taking months to create? Are you trying to create a feature flag for every new line of code before deploying it? A lot of times code can be deployed without using a feature flag, because it's small enough, maybe you are overlooking those cases?
- kelvin0 11y agoTesting flag combinations for one. Also please re-read my post carefully. The details are there.
- UK-AL 11y agoWe have something similar. But I don't like branches, I prefer single trunk development(generally agree with Martin fowler) + feature switches to isolate wip features. We store all binaries built. so we just roll back to the previous binary, which is a single button click for us.
- Jemaclus 11y agoCurious... Why don't you like branches?
- UK-AL 11y agohttp://martinfowler.com/bliki/FeatureBranch.html http://martinfowler.com/bliki/FeatureBranch.html It's a controversial article though.
- harlanji 11y agoI'm pushing for toggles on my team, haven't made a single feature branch in this repo resulting in no merge conflicts (yay). Sofar I'm the only one regularly doing it without feature branches. Running with the idea that just because you can branch cheap doesn't mean you should. Of course toggles are technical debt to be managed, but so are branches. I've found good practice has been mentioning which toggles are available on the README with their defaults (could be generated)... they should be tracked and removed ASAP. I read a newer article that breaks them down into categories http://www.infoq.com/news/2016/02/featuretoggles http://www.infoq.com/news/2016/02/featuretoggles. Toggles over branches are showing value as we run different variants on staging without having to redeploy different builds, but instead changing a launch variable. It's especially clear with 2+ WIP features. We're using environ with Clojure which doesn't have any fancy runtime toggling, but that'd be another thing to look at.
- falcolas 11y agoThe tech debt associated with branches disappears with the completion of the merge request. The tech debt with feature flags doesn't disappear until someone gets around to removing the (now) dead code. Personally, I use both, based on what is best for the feature. Why not, after all?
- oebs 11y agoThanks for the writeup - very helpful. It's always good to get a view of how others are solving the same problems oneself has. That said, the article does come off a bit as trying to be authoritative, but at the same time it doesn't leave enough room for possibilities where alternative approaches may have merit as well (i.e. "this is how to do it" vs. "what worked well for us, ymmv"). Newbies that read this article will think that the principles described are the canonical way and even try and apply them in scenarios where alternatives may prove superior. Other than that, a lot of good advice, well done!
- datr 11y agoI'd be interested in hearing people's thoughts on deploying feature branches to production before merging them. I've generally followed more of a git-flow approach [1]. This seems to have the advantage that multiple feature branches can be grouped and deployed together - thus, avoiding the problem in the article of the deploy queue becoming a bottle neck. [1] http://nvie.com/posts/a-successful-git-branching-model/#creating-a-release-branch http://nvie.com/posts/a-successful-git-branching-model/#crea...
- majewsky 11y agoAt my old team, when we did the migration from SVN to Git, I set up the deployment workflow with mandatory pull requests for everything. And I included a small deployment tool in the QA system where every developer could just click a checkbox next to their branch, and that branch would be added to the QA system (which has a copy of the production data for extended testing). Behind the scenes, it just does an octopus merge of all selected branches into master. Since the codebase was reasonably large, we almost never encountered problems with merge conflicts.
- stympy 11y agoOur preferred deployment method at Honeybadger is to (almost) always merge to master before deploying. We will deploy a feature branch when we want it to be a little easier to rollback to a known good state (by deploying master) for changes that we are nervous about. Those deployments are rare, though, as we have an almost-production environment (it talks to all the production services, but no customers use it) for doing one last smoke test before unleashing code on customers. :)
- ikawe 11y ago> multiple feature branches can be grouped and deployed together I would respectfully argue that this is not a desirable feature. Although you might save some time by deploying multiple branches at once, you cloud the waters of what and how to roll back. I think a better idea is to make deploys easy, quick, and revertible so that you can deploy early and deploy often, and in the event of a rollback, you can rollback just the broken feature.
- richardwhiuk 11y agoThe title of the article was "How to Deploy Software", but almost all of the advice only works for server side software where you have total control over the deployment environment. I'd be much more interested to learn about how people develop mobile and web apps, where feature flags are far less useful as you need to push the entire app to the AppStore, so your iteration time is much slower.
- doublerebel 11y agoI wish native Nodejs deployment was a solved problem, but there really is no comprehensive and universally used tool for deploying Nodejs using Nodejs. ShipIt mentioned in the article is barely a year old, it has a short featurelist and short list of users. PM2 (Keymetrics) is not bad but is buggy, also they seem a bit overwhelmed at the moment. Flightplan is decent but the syntax is more awkward than ShipIt. Every other common language has a stable deployment tool besides Nodejs. I ended up going with Distelli, it's a SaaS but it's fantastic. These days deploys often involve more than just one app or language, and I really prefer a tool that can ship anything. Also, having a GUI to see deployment statuses is invaluable. With those requirements none of the Nodejs tools can stand up to the other, more mature utilities. And rather than have to write all my deploy logic in another language, I just purchase the service.
- kt9 11y agoThanks @doublerebel. For those interested Distelli is at https://www.distelli.com https://www.distelli.com Disclaimer: I'm the founder at @distelli
- supster 11y agoWhat issues have you run into with PM2? I'm running it in production myself, so I'm curious.
- hodoublesy 11y agoI've really enjoyed working with PM2 in production for the last 4 months... although our ramp up has been slow.
- pippy 11y agoI use deploynaut as my deploying tool, and I have to say it's made the process much smoother. Previously I'd simply use git to update a code base or sql workbench/pgadmin to update a database.
- platz 11y agoWhy worry about what is on master, if you save your build artifacts. so that if you need to go back to a the previous behavior, just redeploy the previous productuon build output
- p4lindromica 11y agoYou code is written in golang. You've been compiling it with golang 1.5.1. Then golang 1.5.3 comes out with critical security fixes for their TLS code. That is why you care what is on master: because you need to rebuild if your runtime changes.
- joneholland 11y agoWe deploy straight from master, but tag each build. If you need to rebuild a specific version, it's as easy as checking out the tag.
- softawre 11y agoThis feels like the correct strategy to me (and it's what we do too). Deploying many branches to production seems like a nightmare at any scale.
- Too 11y agoDebugging. Some bug only happens on customer X's installation. You need to know which version customer X is running so you can reproduce the bug in house and know what other impact it might have had.
- paulstovell 11y agoI really enjoyed this article. As an industry, when it comes to something essential like source control, we seem to have converged to a common set of practices and workflows. Deployment is arguably just as important, but I think the practices are very different on different teams. This article is like a more practical version of Continuous Delivery. Three areas that I think would have been worth including: 1. Pre-production. You deploy to test & other pre-prod environments more often than prod. They should use the same scripts/tools/processes as production deployments, only with different permissions. 2. Configuration. Test and production environments will always have different config settings, so no team will ever be able to deploy to more than one environment without encountering this problem. I think there's still an open question around whether those configuration settings should live in the same source control as the code, in a different source control repository, or a dedicated system. Source control systems and sensitive values (passwords, API keys, etc.) don't always mix. 3. Build your binaries once. The article is more focussed on dynamic languages, but for compiled languages, I think this is important. If you branch, compile, deploy to test, test it, get the all clear, then compile again and deploy to production, there's a lot of opportunity for differences between what you tested and what goes to production to sneak in. In fact even for dynamic languages, this might be a valuable practice. What if the JS minifier on one build server is different to another, and the deployed script ends up being different in production to what was tested. Disclaimer: I'm the founder of Octopus Deploy, and these practices might be biased towards enterprisey .NET/on-premises deployments rather than cloud hosted, dynamic language projects.
- Cheezmeister 11y ago> 3. Build your binaries once. Assuming your builds are solidly reproducible like they should be, how do such differences "sneak in"? Granted, truly reproducible builds in the first place are Really Hard(tm).
- paulstovell 11y agoWe put an explanation here (hope it's OK to post the link): https://octopus.com/blog/build-your-binaries-once https://octopus.com/blog/build-your-binaries-once A real world example of this is that when .NET 4.5 shipped, the compilers in .NET 4.5 for 4.0 code produced different output than the .NET 4.0 compilers would have. So installing a system-level update on Windows on a build server would mean Test and Production got different results: http://blog.marcgravell.com/2012/09/iterator-blocks-missing-methods-and-net.html http://blog.marcgravell.com/2012/09/iterator-blocks-missing-... Also, releases move through environments at different times: Monday: 1.0 goes to Test Tuesday: 1.1 goes to Test Wednesday: 1.0 goes to Prod Between 1.0 and 1.1, perhaps you updated Node, or went to Python3 - so your build server had to be updated. Reproducing Monday's build is going to be more difficult the more time that goes by. As you said, truly reproducible builds are hard. Why not just zip the artifacts and use the same files, instead of rebuilding?
- gandhineil 11y agoshoutout to sublime for development
- microcolonel 11y agoThe body text in this article is illegibly thin, please consider moving to weight 600 so that people can read your text. You've worked hard to write it, now it is time for people to read it. :-)
- pmontra 11y agoI didn't notice, but my NoScript blocked the web font and the default font is more legible with that color. In both cases changing the color from rgb(100, 100, 121) to rgb(80, 80, 100) is enough to improve the readability of the text. font-weight: 600 seems a little extreme.
- jorams 11y agoFor some perhaps the color of the text is the only complaint, but for me the font is also illegibly thin [1]. I got around it by disabling the web font, because just setting the font weight to 600 didn't fix the odd shapes [2]. The bold version of the font is also available as a separate font family (AvenirNextLTW01-Bold). It looks much more like a "normal" font weight and is incredibly readable [3]. [1]: http://i.imgur.com/uVHXptR.png http://i.imgur.com/uVHXptR.png [2]: http://i.imgur.com/IXwR6EU.png http://i.imgur.com/IXwR6EU.png [3]: http://i.imgur.com/xgz7EtR.png http://i.imgur.com/xgz7EtR.png
- pmontra 11y agoI noticed that thin fonts are not so thin on high DPI screens. Example: that font is more readable on my 9" 2500x1600 (approx) tablet than on my 1080p 15" laptop. Maybe they are designing for retina Macs.
- TickleSteve 11y ago"How to deploy web software". The software world > web servers. (Sorry to be picky, but some people seem to assume that all software is developed for the web these days whereas the web world is just a significant & vocal minority).
- zeisss 11y agoI think the text works fine for any kind of server software. As he discussed, feature flags also work for downloadable software (desktop/mobile) - the multiple deployments obviously don't make that much sense in that case though.
- collyw 11y agoA great deal of software is web based these days. You install apps on your phone or your desktop. You deploy to a server.
- TickleSteve 11y agotrue, but its still a 'sizeable minority'. As far as number of deployments go, the embedded software world massively outweighs server, client, mobile and desktop. Unfortunately (or fortunately), we in the embedded software world tend to be less vocal than the others.
- collyw 11y agoI wouldn't have though deploy was the correct word for embedded. If its one piece of software I would think of it as an install. If it's coordinating multiple pieces its a deployment.
- LeZuse 11y agoI also recommend Zach's presensation https://speakerdeck.com/holman/how-github-uses-github-to-build-github https://speakerdeck.com/holman/how-github-uses-github-to-bui... [selfpromo:] When we were thinking about deploying our frontend builds, we got inspired by Ember's CLI Deploy pipeline (http://blog.firstiwaslike.com/deploying-ember-cli-apps/ http://blog.firstiwaslike.com/deploying-ember-cli-apps/) and we've built something similar for our Webpack based app (https://github.com/productboard/webpack-deploy https://github.com/productboard/webpack-deploy). Together with Git flow methodology we basically removed all friction from deploying new versions. Would love to hear your thoughts!
- nathancope 11y agoInteresting article. Frank and honest. Good to read the experiences of others. To get the disclaimer out of the way I'm a co-founder of Vamos Deploy. Our product addresses many of the deployment problems that have been discussed here so I thought I'd mention it. We are looking for feedback on the product and an early adopter or two - https://vamosdeploy.com https://vamosdeploy.com I'd like to cover some techie details here. Vamos Deploy encapsulates an application with it's dependancies and runtime config so it can be deployed as one to any number of machines irrespective of the OS (well, Linux and Windows at the moment). This encapsulation is achieved by configuring a 'grid' with all the application package versions, library/runtime dependancies, runtime property values and local repository names (hostnames usually). When the grid is deployed (all via CLI) the respective local repos get updated. You can have multiple grids on a host (in a local repo) thus enabling multiple, differently configured, encapsulated applications that don't conflict. It avoids duplication by the grid sharing the underlying application packages and libraries in the local repo. There is a audit log of all actions for traceability and transparency. A simple ownership model prevents non-prod code getting into production and restricts who can deploy to production. It can be combined quite easily with any config management tool for release orchestration. You don't need RPM/Deb packages or deal with Yum repos. We have concentrated on making it easy to learn and use so max benefit can be attained quickly. I'll stop there. Be interested in anyones feedback here or https://vamosdeploy.com#contact https://vamosdeploy.com#contact for a chat.
- nissimk 11y agoNobody said it here yet, so I just wanted to mention that the design of this blog is really nice. I love the font, links, blockquotes and chapter title images. It also rendered equally nicely on my android phone and my desktop browser. I saw that the author has a github repo for an older blog style for jekyl, but I'd like to see a similar thing for this one. Thanks
- krakensden 11y agoIt broke down halfway through on Android Firefox =(. Reader mode forever.
- holman 11y agoThanks! Was thinking of open sourcing this soon as a one-off. I'll see what I can do. :)
- ctstover 11y agoThe font rendered with iceweasel on debian 8 is illegible.
- sabujp 11y agohttp://spinnaker.io http://spinnaker.io : deployment software made by netflix (king of daily prod pushes), google, and the community for aws, gce, azure, etc
- softawre 11y ago> When you're ready to deploy your new code, you should always deploy your branch before merging. Always. Does anyone actually do this? This seems counterproductive - what if there are multiple branches?
- datr 11y agoI've worked places where we will always deploy a feature request to an ephemeral environment. I find quite a lot of bugs are actually caught by this. But I've never deployed a feature branch into production like the blog post suggests. I had my own questions about this lower down in the comments.
- NLips 11y agoAssuming you have a product/release branch and many others, then I'm guessing the author means you should merge product into your own branch and deploy that, before merging your branch back into product (and deploying it). That should work fine with multiple branches in most cases, so long as you have a system to stop anyone else deploying their branch while yours is running.
- agentgt 11y agoI don't know if I agree with the branch on every deploy particularly if you have a small team and use Mercurial where named branches live forever. I wish the article discussed dependency management more. Instead of branching we tag every deploy and use dependency management heavily (ie maven, npm, etc). That is the project that gets deployed never really has any branches but is composed of lots of smaller projects each in their own repository which may have branches but they have to be released. This approach cuts build time, improves coupling/cohesion as well as facilitate a possible transition of OSS useful components (that do not provide a competitive advantage nor or proprietary). I have seen way too many projects that have this giant monolithic source tree (particularly PHP projects) and thus have to rely on branching much more heavily. I firmly believe this is the wrong approach.
- AlexTes 11y agoI've been arguing for using Git Flow. Reading the post I have to say the stand our lead takes against Git Flow and in favour of very cosy CI is perhaos steonger than I realised. He argues for pushing about as often as possible. With our small team thats very do-able, every push gets tested and linted by the 'blue' or 'green'. You're supossed to only push passing code which you easily can by running the tests and lint locally. So instead of all the pain points mentioned in the post you write passing code, pull and rebase on other passing code, and then push. Little code review, no worries about hasty reverting, few / early conflicts keeping us from trilling each other up or writing incompatible features. The reason I argue for Git Flow? Our tree is an absolute mess. Most often a single chain, of often linearly scrambled features. In other words removing one feature would be hard and require a bunch of legwork, not a couple Git commands. If anyone strongly feels there's a better way for a small team than lightning fast CI let me know!