3 ms·

I thought having a proper continuous deployment helps with development? I want to shorten my learning curve and honestly I have my hands full. Other people cr

by Zeu5 16y ago

I thought having a proper continuous deployment helps with development? I want to shorten my learning curve and honestly I have my hands full. Other people created startups by hiring freelancers to do their coding, so your argument about being exposed to the risks of not being able to fix the very thing that the hires created also applies to them. I am quite sure they were not stopped by that. I do acknowledge that risk you are talking about hence I am also requesting for documentation and a proper handover. Basically, I would like someone to a) implement the setup for me once b) show it to me how it is done c) undo everything and let me do it once. If not possible to do all a, b, c), i dont mind hiring someone to at least do a) and b). Thank you for your reply.

gexla 16y ago
Development and deployment are two different things. Just as development and system administration are two different things. Deployment is actually more in the realm of administration than development. So, I'm not sure you can say deployment helps with development, though it's good for a developer to know about the administration side also. To say "Other people created startups by hiring freelancers to do their coding" is too much of a blanket statement. This is something that has to be carefully considered on a case by case basis. Outsourcing works in some cases and it's a disaster in other cases. You mention that you need someone to hand over the documentation, but that's not the sorts of problems I'm referring to. What happens if the server hits a hardware failure and you have to work outside the documentation to recover? I run into crazy stuff with Administration all the time, it's never so tidy that I can work any sort of documentation people could hand to me. If you don't have a basic working understanding of what you are working with and nobody on staff who can do the same, then you are at the mercy of the same issues you are running into now. I guess what I'm getting at is that you need a process which you can run yourself even when things go very wrong. If you start relying on processes that you can't handle in house (you) then those processes become liabilities rather than assets.
- Zeu5 16y ago
  >I guess what I'm getting at is that you need a process which you can run yourself even when things go very wrong. Okay. So now the question is how do I go about getting that?
  - gexla 16y ago
    Finish the app first. Once you get to a point where you are at least closer, maybe almost to beta then you will see how deployment issues are a problem. I would then start working on your deployment process. At that point, it's all reading and Googling. ;)
    - Zeu5 16y ago
      I understand what you mean. You are telling me not to put the cart before the horse. I am thinking of deployment in the sense that, when i do a push of the repo code to the staging, the unit tests are executed and if all tests are passed, the code is then deployed on the staging proper. Else it will be rolled back. I do not have a) staging b) unit tests c) a hook to run the unit tests when code is deployed to staging I guess the above are important to development yes? Helps to discover bugs easier right?
      - jtheory 16y ago
        A few thoughts on this... Almost anything that can be automated can be done manually (or with minimal scripted automation) first, often with pretty good results. It's generally a good idea to start simple, and don't add complexity and extra work (like configuring/managing automation!) until you are addressing actual needs that you have... at that point, you can measure the pain to decide how much effort to put into the fix. The first step to automated deployment is manual deployment using a checklist. Before automated unit tests, you have to write unit tests, and be able to execute them manually. Before automated rollback, you have manual rollback. Etc.. Are your developers able to run the entire project locally? If so, you are starting off with frequent local deployments, and if you encourage them to implement features in small steps and sync with version control after each step (i.e., at least once a day) then you also have achieved frequent integration builds - each developer is doing them independently. Next, throw in a script that executes all of your unit tests, and run that yourself daily (don't automate it into every build... that'll swiftly make them too slow and devs will start avoiding builds...), then email everyone when something is failing. In other words, with a simple cultural standard -- don't hide in a hole and code for a week, and write unit tests! -- you have already solved (for a small team) most of what continuous deployment addresses. And you haven't put any time whatsoever (or spent money/time hiring someone) into setting up some non-trivial automation yet. The other advantage is that by the time you are seriously ready to automate your build, it may be quite different from what you have now -- it depends on where your project goes, if you make a large pivot, mix in new technologies, and so on. This solution might work for quite a long time; are there good reasons to implement continuous deployment instead, from the start? Other than the cool factor, I don't think so.

by Zeu5 16y ago

gexla 16y ago

Development and deployment are two different things. Just as development and system administration are two different things. Deployment is actually more in the realm of administration than development. So, I'm not sure you can say deployment helps with development, though it's good for a developer to know about the administration side also. To say "Other people created startups by hiring freelancers to do their coding" is too much of a blanket statement. This is something that has to be carefully considered on a case by case basis. Outsourcing works in some cases and it's a disaster in other cases. You mention that you need someone to hand over the documentation, but that's not the sorts of problems I'm referring to. What happens if the server hits a hardware failure and you have to work outside the documentation to recover? I run into crazy stuff with Administration all the time, it's never so tidy that I can work any sort of documentation people could hand to me. If you don't have a basic working understanding of what you are working with and nobody on staff who can do the same, then you are at the mercy of the same issues you are running into now. I guess what I'm getting at is that you need a process which you can run yourself even when things go very wrong. If you start relying on processes that you can't handle in house (you) then those processes become liabilities rather than assets.

Zeu5 16y ago
>I guess what I'm getting at is that you need a process which you can run yourself even when things go very wrong. Okay. So now the question is how do I go about getting that?
- gexla 16y ago
  Finish the app first. Once you get to a point where you are at least closer, maybe almost to beta then you will see how deployment issues are a problem. I would then start working on your deployment process. At that point, it's all reading and Googling. ;)
  - Zeu5 16y ago
    I understand what you mean. You are telling me not to put the cart before the horse. I am thinking of deployment in the sense that, when i do a push of the repo code to the staging, the unit tests are executed and if all tests are passed, the code is then deployed on the staging proper. Else it will be rolled back. I do not have a) staging b) unit tests c) a hook to run the unit tests when code is deployed to staging I guess the above are important to development yes? Helps to discover bugs easier right?
    - jtheory 16y ago
      A few thoughts on this... Almost anything that can be automated can be done manually (or with minimal scripted automation) first, often with pretty good results. It's generally a good idea to start simple, and don't add complexity and extra work (like configuring/managing automation!) until you are addressing actual needs that you have... at that point, you can measure the pain to decide how much effort to put into the fix. The first step to automated deployment is manual deployment using a checklist. Before automated unit tests, you have to write unit tests, and be able to execute them manually. Before automated rollback, you have manual rollback. Etc.. Are your developers able to run the entire project locally? If so, you are starting off with frequent local deployments, and if you encourage them to implement features in small steps and sync with version control after each step (i.e., at least once a day) then you also have achieved frequent integration builds - each developer is doing them independently. Next, throw in a script that executes all of your unit tests, and run that yourself daily (don't automate it into every build... that'll swiftly make them too slow and devs will start avoiding builds...), then email everyone when something is failing. In other words, with a simple cultural standard -- don't hide in a hole and code for a week, and write unit tests! -- you have already solved (for a small team) most of what continuous deployment addresses. And you haven't put any time whatsoever (or spent money/time hiring someone) into setting up some non-trivial automation yet. The other advantage is that by the time you are seriously ready to automate your build, it may be quite different from what you have now -- it depends on where your project goes, if you make a large pivot, mix in new technologies, and so on. This solution might work for quite a long time; are there good reasons to implement continuous deployment instead, from the start? Other than the cool factor, I don't think so.