Как автоматизировать установку среды разработки? [закрытый]

Попробуй это.

IF OBJECT_ID('tempdb..#Production') IS NOT NULL DROP TABLE #Production
IF OBJECT_ID('tempdb..#Bought') IS NOT NULL DROP TABLE #Bought

CREATE table #Production(R_NO int,ProductionDate datetime,ProductionAmount float)
CREATE table #Bought(R_NO int,Boughtdate datetime,Boughtamount float)

insert into #Production(ProductionDate,ProductionAmount,R_NO)
select p.date ProductionDate,sum(Amount) ProductionAmount,row_number()over (order by p.date) R_NO 
from Production P
join Sales  s on p.date=S.date-1   
where orhsysid=1
group by p.date



declare @loop int,@ProdDate datetime
select @loop =max(R_NO) from #Production
while (1<=@loop)
begin

select @ProdDate=ProductionDate from #Production where r_no=@loop

insert into #Bought(Boughtdate,Boughtamount,R_NO)
select Date,Sum(Amount),@loop R_NO from Bought where date=(
select max(date) from bought B
where B.Date<@ProdDate)
group by Date

set @loop=@loop-1
end

select ProductionDate,ProductionAmount,Boughtdate,Boughtamount from #Bought B 
join #Production p on B.R_NO=P.R_NO
79
задан Igor Popov 9 March 2013 в 08:25
поделиться

8 ответов

Существует несколько опций, и иногда полезно их сочетание:

  • автоматическая установка
  • создание образа диска
  • виртуализация
  • управление исходным кодом

Подробная информация о различные варианты:

  1. Автоматическая установка Инструменты для автоматизации установки и настройки различных сервисов, инструментов и файлов конфигурации рабочей станции:

    • Puppet имеет кривую обучения, но мощна. Вы определяете классы машин (блок разработки, веб-сервер и т. Д.), А затем он делает все необходимое для установки, настройки и поддержания блока в надлежащем состоянии. Вы запросили один щелчок, но Puppet по умолчанию - нулевой щелчок, поскольку он периодически проверяет ваш компьютер, чтобы убедиться, что он все еще настроен так, как вам нужно. Он обнаружит, когда файл или режим был изменен, и решит проблему. В настоящее время я использую это для поддержки нескольких коробок RedHat Linux, хотя он способен обрабатывать тысячи. (Не поддерживает Windows с 2009-05-08).
    • Cfengine является еще одним. Я видел, как это успешно используется в магазине с 70 инженерами, использующими RedHat Linux. Его ограничения были одной из причин Puppet.
    • SmartFrog - еще один инструмент для настройки хостов. Он поддерживает Windows.
    • Сценарии оболочки. RightScale содержит примеры настройки образа Amazon EC2 с использованием сценариев оболочки.
    • Установка пакетов. В Unix-системах это можно сделать полностью с помощью пакетов, а в Windows MSI может быть вариантом. Например, RubyWorks предоставляет вам полный стек Ruby on Rails, и все это путем установки одного пакета, который, в свою очередь, устанавливает другие пакеты через зависимости.
  2. Образы дисков Затем, конечно, есть также инструменты создания образов дисков для хранения образа сконфигурированного хоста, так что его можно восстановить на другом хосте. Как и в случае с виртуализацией, это особенно хорошо для тестовых коробок, поскольку их легко восстановить. Постоянное обновление информации по-прежнему остается проблемой - стоит ли создавать новые образы только для распространения изменений в файле конфигурации?

  3. Виртуализация - это еще один вариант, например, создание копий Xen, VirtualPC или Образ VMWare для создания новых хостов. Это особенно полезно с блоками тестов, поскольку независимо от того, какой беспорядок создает тест, вы можете легко восстановить его в чистом известном состоянии. Как и в случае с инструментами для создания образов дисков, поддержание актуальности хостов требует больше ручных действий и бдительности, чем при использовании автоматического инструмента установки / настройки.

  4. Контроль исходного кода После того, как вы установили / сконфигурировали необходимые инструменты, сборка должна заключаться в проверке того, что нужно из репозитория исходного кода и его построении.

В настоящее время я использую комбинацию вышеперечисленного, чтобы автоматизировать процесс следующим образом:

  • Начните с установки базовой ОС на гостевой VMWare.
  • Запустите сценарий оболочки для установки Puppet и извлеките его настройки из управления исходным кодом
  • Puppet для установки инструментов / компонентов / configs
  • Извлечение файлов из элемента управления исходным кодом для создания и развертывания нашего веб-приложения
65
ответ дан 24 November 2019 в 10:18
поделиться

One important point is to set up your projects in source control such that you can immediately build, deploy and run after checkout.

That means you should also checkin helper infrastructure, such as Makefiles, ant buildfiles etc., and settings for the tools, such as IDE project files.

That should take care of the setup hassle for individual projects.

For the basic machine setup, you could use a standard image. Another option is to use your platform's tools to automate installation. Under Linux, you could create a meta-package that depends on all the packages you need. Under Windows, a similar thing should be possible using MSI or the like.

Edit:

Ideally, instead of checking in helper infrastructure, you check in the information that allows the build to generate the helper infrastructure. This is the approach taken by e.g. the GNU build system (autotools etc.), or by Maven. This is even more elegant, because you can (theoretically) generate infrastructure for any (supported) build environment, thus you are not bound to e.g. one specific IDE, and settings in the helper infrastructure (paths etc.) don't need to duplicate the main project settings.

However, this also a more complex approach, so if you can't get it to work, I believe checking in stuff like IDE files directly is acceptable.

13
ответ дан 24 November 2019 в 10:18
поделиться

если вы используете версию linux, вы, вероятно, имеете систему управления пакетами: думает .rpm для fedora / redhat или .deb для ubuntu / debian. многие из описанных вами вещей уже имеют доступные пакеты: svn, eclipse и т. д. вы можете свернуть свои собственные пакеты для программного обеспечения, специфичного для компании, создать репозиторий (возможно, доступный только в локальной сети), и тогда ваши настройки могут быть сокращены до одного bash-скрипт, который добавит репозиторий компании в /etc/apt/sources.list (debian / ubuntu), а затем вызовет команду наподобие


/home/newhire$ apt-get update && apt-get install some complete package list

, вы можете использовать buildbot , чтобы затем автоматизировать обычные сборки для пакетов компании которые часто меняются.

0
ответ дан 24 November 2019 в 10:18
поделиться

Если вы используете машины в стандартной конфигурации, вы можете создать образ диска с новой, идеально сконфигурированной установкой - это очень популярный подход во многих корпорациях (и не только для разработчиков). Если вам нужны отдельно сконфигурированные ОС, вы можете tar-bz2 всех добавленных и измененных файлов, как только сконфигурированная ОС будет превращена в желаемую настройку, и просто распаковать ее как root, чтобы создать желаемую среду с нуля.

0
ответ дан 24 November 2019 в 10:18
поделиться

Всегда есть возможность использовать виртуальные машины (см., Например, VMWare Player ). Создайте одну среду и скопируйте ее для каждого нового сотрудника с минимальной необходимой конфигурацией.

1
ответ дан 24 November 2019 в 10:18
поделиться

Используйте puppet для настройки среды разработки и производства. Использование первоклассной системы автоматизации - единственный способ масштабирования ваших операций.

3
ответ дан 24 November 2019 в 10:18
поделиться

Мне нравится использовать Virtual PC или VMware для виртуализации среды разработки. Это обеспечивает стандартную «среду разработки», которая может использоваться разработчиками. Вам не нужно беспокоиться о программном обеспечении, которое пользователь может добавить в свою систему, что может конфликтовать с вашей средой разработки. Это также дает мне возможность работать с двумя проектами, где среды разработки не могут быть одновременно в одной системе (используя две разные версии базовой технологии).

7
ответ дан 24 November 2019 в 10:18
поделиться

На прежнем месте у нас было все (и я имею в виду ВСЕ) в SCM (прозрачный, затем SVN). Когда новый разработчик может войти, они установили ClearCase | SVN и высосали репозиторий. Это также обрабатывает случай, когда вам нужно обновить конкретную библиотеку lib / tool, поскольку вы можете просто попросить команды разработчиков обновить свою среду.

Для этого мы использовали два репозитория, поэтому код и tools / config жили в разных местах.

1
ответ дан 24 November 2019 в 10:18
поделиться
Другие вопросы по тегам:

Похожие вопросы: