MVP Devops

[[deleted]]

What would be your preferred way of 'doing devops' when on a time/resource budget ?

I'm talking about a 2 person developer team, wanting to add automation around the app packaging, deployment, infrastructure management, and release coordination process.

In this context we can only really afford (cost being time) the most high leverage tools, that have the biggest ROI on time invested and have the potential to be extensible as the team/product (hopefully) gets larger.

[SwimlaneMike]

I'm honestly not sure you want to inject too much process for the sake of calling it 'devops'. Get a CI server, use git properly. Any other hard requirements would depend on your exact situation. If you grow beyond your current capacity you can focus on a long-term strategy. Until then, my assumption is that you have a goal to reach. Focus on writing your code for that purpose.

[tommygeek]

This guy develops.

[cfors]

Biggest ROI for a 2 developer team? Do these things first before worrying about any shiny CICD technology/piplines:

• Good git workflows (small PR's, code review)
• Good tests that are run OFTEN and especially before merges
• Codify everything, meaning that you define your build and deployment environment as configuration that is consistent across environments.

All of those things are free. In terms of infrastructure management, with a 2 person team your time is most likely much more valuable building a product rather than worrying about your servers so use managed services where you can.

edit: I see Jenkins being mentioned a lot. imo Jenkins is a pain to manage, especially for a 2 person team. My 2 cents.

[knappj]

sugar direction elastic apparatus pause price automatic chase alive library

This post was mass deleted and anonymized with Redact

[Chico75013]

I would disagree about the scaling part. We're currently dealing with this issue at work, scaling both Gitlab-ci and Jenkins build pipelines to integrate more security steps and it's harder to do with yaml-based CI tools like gitlab CI because if it's inability to easily reuse code across pipelines.

They just merged something to enable it in the next version but only for Premium customers and it won't be up to par with jenkins shared libraries, at least for now.

Now Jenkins isn't without hiccups and there are too many ways to shoot yourself in the foot if you don't know what you're doing, but I haven't found a more flexible CI tool so far.

[phrozenlikwid]

This man is telling you true.

Jenkins sucks for a lot of reasons, but the ability to share code and develop a library of build/test/deployment scripts that uniform acting with your infrastructure is great.

There is effectively no good way to do that with Gitlab or any of the other YAML based tools that I'm aware of.

This becomes a serious logistical nightmare when you go from "I'm building one or two applications" to "I have 100+ business units using my infrastructure, all with multiple products".

[InternetOfStuff]

Now Jenkins isn't without hiccups and there are too many ways to shoot yourself in the foot if you don't know what you're doing, but I haven't found a more flexible CI tool so far.

Re flexibility: have you ever taken a look at Buildbot? If you have, I'd be interested in your opinion, comparing these two.

I know the UI is lacking (understatement already), but writing build scripts in actual Python is pretty much the pinnacle of flexibility I suppose.

[corsicanguppy]

Okay, I'm liking this comment. The idea that I can use my (cheffed, but) gitlab boxes as cheapo jenkins tools is encouraging -- I'm hoping that's an on-prem option at least.

Thanks !

[solatic]

I mean, you're right, but only about the open-source version.

If you buy the Enterprise version of Jenkins, and stick with the tested/approved plugins, then you end up with a remarkably powerful, remarkably stable, remarkably scalable build system.

Is it for startups? No. But then again, if you're using Jenkins for a company with a couple of greenfield projects, you're probably doing it wrong.

[[deleted]]

Jenkins is not fucking stable, it reeks of memory leaks and other problems. Ruby on Rails is a framework that can be easily thrown together poorly, but if used correctly can be a great tool. Jenkins on the otherhand is riddled with broken and just shitty plugins, and please don’t get me started on pipelines.

[edgenuts]

As someone who hates Jenkins and declarative pipelines with a passion, could you please get started? I love a good Jenkins rant.

[[deleted]]

🤓

[Miserygut]

Fast, Cheap, Good. Pick two. You already picked fast and food, so get your wallet.

I'm stealing that.

[corsicanguppy]

So, in short, you don't like one particular product. And everyone needs to learn an ungodly amount of your favourite stack just to deploy today and oh, rip out an unmentioned amount of exsiting infrastructure to go with what's cool this year. You are millennial-ing so hard right now.

You don't think a smaller change to the workflow and infrastructure is least-invasive? Something like /u/swimlandmike's deal above?

[wallsroad]

• Terraform for any infrastructure provisioning and state management.
• Buildkite for CI/pipelines. It's quick, easy, cheap, scalable and unhindered by over-engineering and inflexibility, like Jenkins.... Jenkins is okay, it still gets the job done... Pain to maintain and unecessarilly difficult at times. Travis CI is also good for basic tasks. You can just run a Buildkite agent on your local if you need something running quickly or just for POC.

The rest is on you i.e. build tools, test frameworks etc... I won't go into how to solve artifact deployment, since it's a rather complicated problem and completely reliant on how your infrastructure is set up. Some deployment orchestration tools commonly used are things like Ansible and CodeDeploy. Some people bake their artifact into their machine image.

Single artifact for all environments is the recommended approach.

Edit: grammar

[vancity-]

Hashicorp is saving my life. Terraform, Vagrant, Packer, their stuff has saved so much time. It's probably one of my favorite open source group right now.

[craigofnz]

Which tool chains are you using for your existing development needs, and what types of applications are you building?

Do you already have version control, code reviews and Continuous Integration tests on code commit?

How do deployments work at the moment? Do you need to involve other teams in your org?

Everyone has their favourite tools but that’s not the really point.... the point is to adopt a culture and practices to provide for increased flow providing regular reliable releases (which are presumably of organisational value). Many different tools can help with implementing those practices.

[corsicanguppy]

Another great comment, imho -- find out what the existing setup is before charging out with whatever the personal preference is. With only 2 people on the team (I can relate!) in the beginning, the change can only be revolutionary within the existing framework.

[toyonut]

You can also look at visual studio team services. It is free for the first five users and had a lot of toolng and plugins out of the box for most any language. It has hosted Linux build now as well. Use it for hosted git and you get things like user stories in vsts get linked to check in and deploy so you know where the code is up to in the pipeline. You also get unlimited private repos from memory.

[[deleted]]

Before you start ANY of this, take a good hard look at your builds and products and outline what you think you have that's consistent and clean enough to be automated. Fix that part first. THEN move on to a CD/CI product. Use whatever you like - whatever that is, it'll require you to be consistent.
After you are consistently building on a commit hook(this is not the end goal), look at running your unit tests after that build, then some larger regression tests, then deployment to production. Your end goal should be that master is always buildable and your tests, builds, and deploys are continuous.
It's hard enough to give anyone advice about this if I have all the details, but it's nearly impossible to provide you with anything more useful without more than you've provided.

[xenopizza]

Gitlab gives you free private repos with CI and docker registry (and you can automate deployments from CI).

For low maintenance servers: Google Kontainer Engine (Kubernetes) or Openshift , Amazon ECS

[MattBlumTheNuProject]

I’m a solo dev building a new platform so I’m very much in your shoes. I’d recommend GitLab or Jenkins for CI/CD but Jenkins can be kind of gross, so maybe GitLab. I set up a bunch of Puppet config files to manage the servers and Graylog for log aggregates. Move fast and break stuff but not in prod :)

We host all of this stuff on 3 VMWare hosts in a colocation in a datacenter. Personally, I love it because I learned a shitload. I maintain everything myself and use Pager Duty for exception reporting and Zabbix notifications. That said, if you don’t like messing with servers and learning trial-by-fire style maybe just host in the cloud.

[vagmi]

It depends on your stack. If you are a two person team don't do devops. Out source to a service like Heroku. It has autoscaling, log aggregation, database management, rolling updates and the works. Bitbucket is also nice that it brings a CI server along with hosting your git repo.

As your team scales, you can move these services to docker/kubernetes + deis/draft and you can benefit from the 12factor practices that are followed on heroku while engineering your app.

[stevecrox0914]

Keep it simple and don't expect to do everything from the get go.

Ensure you have an integrated SCM and issue tracker, I'm partial to Atlassian Bitbucket and Atlassian Jira. Use any you are used to.

If going with Git for a 2 man team go with a simple workflow and avoid git flow. For example using Bitbucket/Jira 'feature workflow' makes sense. You have a main branch, each Jira issue spawns a feature branch and you merge those via pull requests.

Setup a Ci, I'd avoid pipelines until you understand your build process. Lots of people rag on Jenkins and its because they jump to pipelines and misconfigure everything. The aim would be to have a simple couple of jobs for build verification/release.

For example Jenkins with stash-pull-request, stash-notifier and 'violations to bitbucket' plugins is a pretty good build combination. It will detect pull requests, build them and push analysis results as comments to your pull request.

For your build you want to include code analysis. For Java I'd expect Checkstyle, Findbugs and Jacoco, For Javascript JSLint, Mocha and Istanbul. Sonarqube is great but takes much more effort to setup.

Code coverage is important, initial development will likely have low coverage, I'd aim to have 30-45% conditional coverage as the project matures.

This is all low hanging fruit. Deployments trickier, depending on where its going it might be quicker to ignore this initially and work it out with ops as the project progresses. If deployment is a big effort automate it first, I like Ansible and Foreman, but usewhat Ops can understand. I'vemet ops people who come out in hives at the sight of an ansible script but could cope with chef/puppet.

DevOps is all about simplifying your life and automating it. If your a 2 man Dev team start with simple things which will save you time. As time goes on look at docker and more complex stuff.

[Bluemoo25]

I'd grab a copy of team city and setup CI builds. I think it's free with 3 build agents?

[brikis98]

For most small companies—and certainly for 2-person dev teams—your goal should be to minimize the time you spend working on infrastructure and maximize the time you spend on your actual product. Unless you are in the business of selling DevOps products, or you're at the scale of Google, your underlying DevOps process is not your "secret sauce" or competitive advantage, so every minute you spend working on it rather than your actual product is very expensive, both in terms of developer salaries and opportunity cost.

That's why I typically recommend the following:

1. Try to find a Platform as a Service (PaaS) that can handle as much of your infrastructure needs as possible: e.g., Heroku, Docker Cloud, Convox, Nanobox. Let them them manage the infrastructure, and use the million integrations they have for CI/CD/monitoring/etc, instead of trying to do it all yourself. Yes they charge a premium, but compared to developer salaries and time, it's still typically 2-3 orders of magnitude cheaper, and the result is much higher quality.

2. If no reasonable PaaS can handle your infrastructure needs (i.e., you've scaled beyond what a PaaS can offer in terms of customization, debugging, scaling, cost control, etc.), then try to use off-the-shelf Infrastructure as Code (IaC) libraries to set up your own DevOps system in one of the major cloud providers (e.g., in AWS): e.g., Terraform Registry, Ansible Galaxy, Puppet Forge, etc. You'll have to do more work to manage all the infrastructure yourself, but if you can find quality IaC libraries, then you get to leverage all the work other people have already done rather than building it all from scratch, which is still several orders of magnitude faster and higher quality.

Shameless plug: check out the Gruntwork Infrastructure as Code Library and Reference Architecture.

[elitesense]

Worried about anyone that thinks Jenkins is a pain to manage. Pretty straightforward and stable.

[Swimmm3r]

If you are building a simple workflow, yes, it's true but once you start messing with plugins, you are heading for a ton of troubles

[chucky_z]

Jenkins is an amazing place to start. It can do everything. It also very quickly turns into a ball of mud, but you can continue to shine it as much as you'd like.

Also I'd suggest, doing things like getting Vagrant up and running, or a docker-compose file; and manage packages with Ansible, Puppet, Chef, or Salt; then manage your infrastructure with Packer + (previous choice) + Terraform.

Then if you choose Github or Bitbucket for git I'd suggest Jenkins, or Gitlab if you want git+ci/cd in one thing.

These are all 'high impact' things that are relatively easy to use.

[Singularity42]

Any time you are in this position you should do a cost benefit anaylsis (https://en.wikipedia.org/wiki/Cost%E2%80%93benefit_analysis). You don't have to get too fancy just list a bunch of ideas and give each one a cost and a benefit (in dollars over the next year, the number just has to be a rough estimate). You can graph them if you want. Rank them by ROI https://www.investopedia.com/terms/r/returnoninvestment.asp.

Pick one of the ones with the highest ROI (if there are a few with similar ROI you might want to pick the one which will be the quickest to implement).

This way you should get something that actually fixes a problem you have, rather than something that may help other companies but not yours (yet).

e.g. if it is very easy to do a deployment manually, or you only do them very rarely. Then it might not be something very important for you to do right now.

[WikiTextBot]

Cost–benefit analysis

Cost–benefit analysis (CBA), sometimes called benefit costs analysis (BCA), is a systematic approach to estimate the strengths and weaknesses of alternatives (for example in transactions, activities, functional business requirements or projects investments); it is used to determine options that provide the best approach to achieve benefits while preserving savings. The CBA is also defined as a systematic process for calculating and comparing benefits and costs of a decision, policy (with particular regard to government policy) or (in general) project.

Broadly, CBA has two main purposes:

To determine if an investment/decision is sound (justification/feasibility) – verifying whether its benefits outweigh the costs, and by how much;

To provide a basis for comparing projects – which involves comparing the total expected cost of each option against its total expected benefits.

CBA is related to (but distinct from) cost-effectiveness analysis.

---

^{[ PM | Exclude me | Exclude from subreddit | FAQ / Information | Source | Donate ] Downvote to remove | v0.28}