5 ms·

I wish I hadn't experienced this exact scenario as well. I actually worked at a publishing company where I discovered the previous team building their major edu

by foldor 8y ago

I wish I hadn't experienced this exact scenario as well. I actually worked at a publishing company where I discovered the previous team building their major education platform didn't know there was such thing as source control. Their method for sharing multiple team members changes was to email the full project to one person every Friday who would manually open a merging tool and merge all changes themselves. They would then send out the updated code base to all people again. Because of this method, they were afraid to delete any stale code, and just prefixed old versions of functions with XX. As you can imagine, inheriting that code base was a nightmare to deal with.

WrtCdEvrydy 8y ago
Someone created a jenkins pipeline that would deploy code in a zip file into prod.
- mattmanser 8y ago
  Am I missing something? Isn't this exactly how deployment servers actually work? I'm not into Java development, but this sounds fine on the face of it, without you giving the context of how this pipeline is triggered.
  - WrtCdEvrydy 8y ago
    Developers had a copy of code in a google drive... they'd modify it, zip it and overwrite the one in google drive, copy it to the network folder which would deploy it and delete it from the network folder... in 2016.
  - Bartweiss 8y ago
    In theory it sounds alright. It's not great, because Jenkins is usually layered with some existing deploy framework that makes "deploy a zip file" pretty suspect. A healthier setup would look more like "build a Tomcat war file Maven, upload and deploy that with Jenkins". But in context, it sounds like the horror is that people were making and transferring a zip from local code rather than building from the tip of source control.
- debaserab2 8y ago
  That’s a pretty standard CI process - zip files are often your deploy artifact (using, for example, git archive)
  - WrtCdEvrydy 8y ago
    Yeah, except the zip file was... the input. You pulled the code from google drive, modified it, pushed it to PROD, checked it and moved it back to google drive... and asked the other developers to update.
yibg 8y ago
I remember having this debate many years ago. Would it be better to introduce a team with no source control knowledge to something like svn first or straight to git? Svn is easier to understand and use, but then you’d have to break some existing habits to get to git. But going straight to git might be a big step and cause reversion back to whatever system was already there.
- srean 8y ago
  Here's a vote for going straight to Mercurial (a lot easier to grok) and link to Joel Spolky's excellent tutorial https://web.archive.org/web/20180903164646/http://hginit.com/ https://web.archive.org/web/20180903164646/http://hginit.com...
- ehnto 8y ago
  Straight to git but have a simple and clear branching strategy. As in a full written procedure for the three main events of git. "Get code, commit code, push code". Then disallow direct commits to master to make people work in feature branches and make merge requests through the platform (github /lab/ bitbucket). I find merging and branching locally is where people normally trip up. Git GUI tools always make git seem way more complicated than it is so depending on the teams platform I would recommend cli from the start.
  - jliptzin 8y ago
    I would not start people new to git on cli. That's how you get someone's entire Camera Uploads directory committed to master (I've seen it before). I recommend Git Tower. I use it for most tasks actually even though I am comfortable in the CLI too. It tends to stop me from doing stupid things before I do them.
    - seanwilson 8y ago
      You can probably assume a lot of people who aren't using version control aren't using the terminal either. GUIs are generally much better at CLIs at giving you an overview of what's happening and what actions are available too.

by foldor 8y ago

WrtCdEvrydy 8y ago

Someone created a jenkins pipeline that would deploy code in a zip file into prod.

mattmanser 8y ago
Am I missing something? Isn't this exactly how deployment servers actually work? I'm not into Java development, but this sounds fine on the face of it, without you giving the context of how this pipeline is triggered.
- WrtCdEvrydy 8y ago
  Developers had a copy of code in a google drive... they'd modify it, zip it and overwrite the one in google drive, copy it to the network folder which would deploy it and delete it from the network folder... in 2016.
- Bartweiss 8y ago
  In theory it sounds alright. It's not great, because Jenkins is usually layered with some existing deploy framework that makes "deploy a zip file" pretty suspect. A healthier setup would look more like "build a Tomcat war file Maven, upload and deploy that with Jenkins". But in context, it sounds like the horror is that people were making and transferring a zip from local code rather than building from the tip of source control.
debaserab2 8y ago
That’s a pretty standard CI process - zip files are often your deploy artifact (using, for example, git archive)
- WrtCdEvrydy 8y ago
  Yeah, except the zip file was... the input. You pulled the code from google drive, modified it, pushed it to PROD, checked it and moved it back to google drive... and asked the other developers to update.

yibg 8y ago

I remember having this debate many years ago. Would it be better to introduce a team with no source control knowledge to something like svn first or straight to git? Svn is easier to understand and use, but then you’d have to break some existing habits to get to git. But going straight to git might be a big step and cause reversion back to whatever system was already there.

srean 8y ago
Here's a vote for going straight to Mercurial (a lot easier to grok) and link to Joel Spolky's excellent tutorial https://web.archive.org/web/20180903164646/http://hginit.com/ https://web.archive.org/web/20180903164646/http://hginit.com...
ehnto 8y ago
Straight to git but have a simple and clear branching strategy. As in a full written procedure for the three main events of git. "Get code, commit code, push code". Then disallow direct commits to master to make people work in feature branches and make merge requests through the platform (github /lab/ bitbucket). I find merging and branching locally is where people normally trip up. Git GUI tools always make git seem way more complicated than it is so depending on the teams platform I would recommend cli from the start.
- jliptzin 8y ago
  I would not start people new to git on cli. That's how you get someone's entire Camera Uploads directory committed to master (I've seen it before). I recommend Git Tower. I use it for most tasks actually even though I am comfortable in the CLI too. It tends to stop me from doing stupid things before I do them.
  - seanwilson 8y ago
    You can probably assume a lot of people who aren't using version control aren't using the terminal either. GUIs are generally much better at CLIs at giving you an overview of what's happening and what actions are available too.